Compiler features

[Flash Gordon]

Flash Gordon said:

Kelsey Bjarnason wrote:
[snips]

On Sat, 27 Jun 2009 01:23:28 +0200, jacob navia wrote:

If you use C+ Windows API you aren't tied to anybody.
Really? Where do I get the Windows API for my Commodore 64? Or
even for my laptop, which runs Ubuntu?

If you program for Ubuntu you are tied to GTK or to QT.

Rubbish. For a start there is all the KDE based software available
for Ubuntu (including a version of Ubuntu that uses KDE instead of
Gnome as the Desktop). Then there are all the other GUI front
ends.

In which case you're tied to those instead. You have not nullified
Jacob Navia's point, merely modified it slightly.

I missed that Jacob mentioned QT, but my point stands, at least as I
read what he said. Using Ubuntu does not tie you to a particular GUI or
toolkit (or a small range of them). There are a large range available.
Now, of course, if you tie yourself to GTK you are tied to GTK, but that
is not what Jacob said, has no real relation to Ubuntu, and does not
even tie you to flavours of Unix.

Nor, alas, is it implemented on /every/ platform. So you can
palliate portability problems, but not eliminate them.

Agreed. However, it is the increased portability that give it a big
advantage over the Windows API (when you are targeting Windows that is
normally what you customers already have, so making use of the Windows
API does not mean spending more money with MS than would be spent anyway).

This needn't be such a huge problem, actually, if you are careful to
isolate the non-portable parts of the program. I have worked on one
project where this was done extremely effectively, by dint of some
pretty darn good programming, but one can get reasonable returns
simply by separating "business logic" from "presentation logic".

I agree you can do it. In fact, with a well written client-server
application the "presentation logic" will be running on a different box
to the "business logic", so it's not only possible it's done! If course,
you then have to isolate the network handling, but that is even easier.

Um, it's not rubbish when seen from the perspective of someone who
only uses one platform and cannot conceive of the need to use any
other platform.

It may be how it appears to someone like that, but how it appears to
them does not alter the fact that it is still tied to Microsoft!

 

[Antoninus Twink]

But here I disagree. If you write 99% of your program in ISO C (and
yes, 99% is about the right figure), and put the other 1%, the
non-portable stuff, into its own module(s), then you can rewrite
that 1% for each new platform you need to support, which is a darn
sight faster than rewriting the whole thing, which means you aren't
tied to anything.

Yeah, sure, Heathfield.

As usual, you expect us to believe that you are a super-programmer who
is not bound by the same limitations as us mere mortals. In fact, all we
conclude is that you have *no* significant real-world programming
experience.

So you can write a GUI application like the payroll suite the OP was
interested in, and put 99% of the core functionality into a portable
library with only 1% non-portable code to support the GUI?

I call bullshit.

Just assembling the main window will be tens or hundreds of lines of
code. Tens of widgets all need their own set of callback functions. And
this all comes to 1% of the code?

Bullshit. Simple, unadulterated bullshit.

 

[jacob navia]

Yeah, sure, Heathfield.

As usual, you expect us to believe that you are a super-programmer who
is not bound by the same limitations as us mere mortals. In fact, all we
conclude is that you have *no* significant real-world programming
experience.

So you can write a GUI application like the payroll suite the OP was
interested in, and put 99% of the core functionality into a portable
library with only 1% non-portable code to support the GUI?

I call bullshit.

Just assembling the main window will be tens or hundreds of lines of
code. Tens of widgets all need their own set of callback functions. And
this all comes to 1% of the code?

Bullshit. Simple, unadulterated bullshit.

True, but since noooone of the regs knows anything about GUI programming
he can say anything he wants. They will always agree.

 

[Beej Jorgensen]

Just assembling the main window will be tens or hundreds of lines of
code. Tens of widgets all need their own set of callback functions. And
this all comes to 1% of the code?

You might be underestimating the complexity of payroll-related law in
certain countries. ;-)

-Beej

 

[Lew Pitcher]

Probably a joke post but all you need for payroll is any 1980s computer,
BASIC, and a couple of spare weekends.

I see that you've never written a payroll program for a SME, let alone a
large company. Such a program (a suite, actually) does more than multiply
hours worked by hourly rate (think withholding taxes, pension payments,
[Un]Employment insurance, union dues, overtime rates, vacation days, etc],
and quite often has major hooks into the enterprise Human Resources tools.

Four mandays of BASIC development won't cut it.

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

 

[Flash Gordon]

On June 27, 2009 05:20, in comp.lang.c, BartC ([email protected]) wrote:

Probably a joke post but all you need for payroll is any 1980s computer,
BASIC, and a couple of spare weekends.

I see that you've never written a payroll program for a SME, let alone a
large company. Such a program (a suite, actually) does more than multiply
hours worked by hourly rate (think withholding taxes, pension payments,
[Un]Employment insurance, union dues, overtime rates, vacation days, etc],
and quite often has major hooks into the enterprise Human Resources tools.

You forgot the interface to the accounts package, possibly interfaces to
project cost management software (something I've done from the other
side), possibly and interface to BACS or some other electronic banking
system...

Four mandays of BASIC development won't cut it.

4 man-days might not be enough to make a serious start on reading up on
the interfacing requirements.

 

[GPS]

Probably a joke post but all you need for payroll is any 1980s computer,
BASIC, and a couple of spare weekends.

I shared your perception of payroll programming, until I read this:
http://www.c2.com/cgi/wiki?WhyIsPayrollHard

-George

 

[user923005]

I shared your perception of payroll programming, until I read this:http://www.c2.com/cgi/wiki?WhyIsPayrollHard

Tax laws
Overseas workers
Legal compliance
GAAP verification of correctness

When you think about it, it is something that pretty well has to be
perfect in every single aspect.

 

[Antoninus Twink]

huh? Maybe in some arcane UI such as Win32, but in most high level UIs
it takes a few lines.

Are you joking?

The only way I know of specifying a form in any library in a few lines
is to design the form in some GUI beforehand, thereby sacrificing a lot
of control over how the form looks and where its widgets get placed,
besides being a slow and clumsy way of doing things.

 

[Squeamizh]

Are you joking?

The only way I know of specifying a form in any library in a few lines
is to design the form in some GUI beforehand, thereby sacrificing a lot
of control over how the form looks and where its widgets get placed,
besides being a slow and clumsy way of doing things.

I am not sure what is meant by "assembling" the main window, but
regardless of the meaning, saying you can do it in a few lines
certainly sounds ridiculous.

Perhaps this is all just some big misunderstanding, and Mark McIntyre
can provide an example of what he's talking about. If it only takes a
few lines, then demonstrating his point should be trivial.

 

[jacob navia]

huh? Maybe in some arcane UI such as Win32, but in most high level UIs
it takes a few lines.

Sure. This confirms what I have said all along:

regs do not have a clue of what is GUI programming.

Since it is only a few lines, just give us an example please.

I can give you an example:

#include <stdio.h>
int main(void)
{
printf("hello\n");
system("pause");
}

will provoke the opening of a DOS window...

 

[Keith Thompson]

Sure. I have an app that pops up a window, displays an analogue clock,
and counts down from some point defined by the commandline, before
beeping thrice and exiting. It takes 40 lines.

40 lines of what?

[...]

 

[Squeamizh]

Sure. I have an app that pops up a window, displays an analogue clock,
and counts down from some point defined by the commandline, before
beeping thrice and exiting. It takes 40 lines.

Antoninus said it would take "tens or hundreds of lines." I'm having
a difficult time understanding how that criterion doesn't fit your 40-
line example.

Well, I was responding to a troll, and he took my bait, and you
responded to his further trolling, so....

If that is your interpretation of events, then the only troll here is
you.

 

[Nobody]

Are you joking?

The only way I know of specifying a form in any library in a few lines
is to design the form in some GUI beforehand,

You don't have to use a GUI, but the sane way to design a UI is with
a data file, not dozens of create_widget() calls.

thereby sacrificing a lot
of control over how the form looks and where its widgets get placed,

You're thinking of Windows, where everything is placed at fixed
coordinates. Unix UI builders (Glade, UIL) specify relative placements,
with the final positions determined by the container's packing algorithm,
the same as if you create the widgets in the code.

besides being a slow and clumsy way of doing things.

It's hard to get much slower or clumsier than creating the UI
programmatically.

 

[Richard Bos]

I shared your perception of payroll programming, until I read this:
http://www.c2.com/cgi/wiki?WhyIsPayrollHard

I thought payroll processing was easy. That lasted until I _got_ my
first paycheck, and it suddenly became very important indeed that they
got it right in every last detail.

Richard

 

[Richard Bos]

But the point is, if the HLL you're using provides suitable features you
can do it easily. Win32 on its own is too low level to offer this sort
of sopistication but there are plenty of higher-level UI libs that do.
These also have the advantage that they work on different underlying
graphical display subsystems, The above 40-liner would work on Windows
(95-Vista), X-11, MacOs, DecWindows, and probably a bunch of others.

Possibly, but would it look like a normal Windows program, an X-11
program, the usual MacOs program and a standard DecWindows program
respectively, or would it look like a *shudder* JavaApp on all of them?

Richard

 

[Richard Bos]

Yes.

Is it, then available for C? I want one of those, but I've only found
one for C++.

Richard

 

[Antoninus Twink]

Sure. I have an app that pops up a window, displays an analogue clock,
and counts down from some point defined by the commandline, before
beeping thrice and exiting. It takes 40 lines.

Great.

Give up your trolling, Mackintyre. As you know full well, the context
was a substantial GUI application (specifically a payroll suite), not a
silly little toy with a single window containing a single widget.

Even then, 40 lines for something as simple as that makes my point
pretty well.

 

[Squeamizh]

I said it would take just a few. I'm having a difficult time
understanding how that criterion doesn't fit my 40 line example.

This is a good example of how forum discussions often degenerate into
a waste of everyone's time. There seems to always be a certain
element of participants who are either too dishonest or too stupid to
take into account the entire context of a thread before posting. In
this case, you appear to have forgotten what you yourself posted when
you attempted to contradict Antoninus Twink. Now, by agreeing that
your 40-line example does support his claim, you make it obvious that
your motivation was not to spawn an exchange of ideas, but to publicly
argue with someone you dislike. Not true? Then please clarify your
part in the below exchange:

Antoninus Twink: Just assembling the main window will be tens or
hundreds of lines of code.
Mark McIntyre: huh? Maybe in some arcane UI such as Win32, but in most
high level UIs it takes a few lines.

By the way 40 lines is the /entire programme/. The window part of it was
only a few.

I asked you for an example, and you provided a vague description of
some perl script. I realize that since you are incapable or unwilling
to consider the appropriate context before opening your big fat mouth,
I'm likely wasting my time, but if you actually go back and read
Antoninus's post, the discussion specifically and explicitly regarded
"ISO C." In addition, the program being discussed is a payroll
application that would actually be used in the real world, not a silly
script which beeps three times (which, I guess you are amused by?).
When I asked you to illuminate your point with an example, I wrongly
assumed you would take some basic context into consideration. Now I
know better.

Evidently you've not been around long enough to spot Twink's trolling.

I don't care much about who said something; the substance of what is
actually said is a lot more interesting. If you can't support your
side with a logical argument--and clearly you cannot--then simply
disparaging someone's character is not a valid substitute. What's
more, you admitted that you baited Antoninus somehow, and that he
ended up "taking the bait." That sounds like a plain admission of
trolling to me.

I notice you didn't comment on this part.

My post addressed your claim that it would take only a few lines of
code to build the main window of a GUI. I guess you think you scored
some big points by describing something very obvious that has already
been posted elsewhere in this thread, but you failed to notice that it
is entirely irrelevant.

 

[BartC]

Probably a joke post but all you need for payroll is any 1980s
computer, BASIC, and a couple of spare weekends.

I see that you've never written a payroll program for a SME, let
alone a large company. Such a program (a suite, actually) does more
than multiply hours worked by hourly rate (think withholding taxes,
pension payments, [Un]Employment insurance, union dues, overtime
rates, vacation days, etc], and quite often has major hooks into the
enterprise Human Resources tools.

Four mandays of BASIC development won't cut it.

I've done a wages program for a small company, admittedly one trading on a
small island with simpler rules than the US. And it was part of a larger
system with which it shared some data.

Probably it was even simpler than the Basic code I was suggesting.

For that matter, how was this done on a typical 1980s microcomputer, perhaps
with Basic, and with limited memory? Assuming payroll systems were available
on such machines.

The OP mentioned the work was currently done manually, and any sort of
automation could help.