WHY

[hrlngrv]

yes, programmers are a waste of time.

!

Your browser and newsreader (not to mention your OS) were written in
SQL by DBAs?!

Most programming languages out there are obsolete.. C++ or C# or Perl-- give
me a break.

Ever tried to automate monitoring of system logs without using Perl or
some other scripting language? Definitely not fun!

Ever tried to write a device driver without using C or Assembler?
(Disclosure: I've written only one, following a cookbook procedure in
C, that provided a power on password with certain validation rules for
those passwords, and had to be loaded from CONFIG.SYS.)

If you're talking about generating reports, then I'd only agree that
most languages are overkill and not the best tool for the task (aside
from Perl and similar scripting languages summarizing system logs).

www.sqlmag.com has a new report that says that like 80% of the top database
people in the country use VB or VBA or VB.net.

Top database people? Which country? That sqlmag url redirects to

http://www.windowsitpro.com/SQLServer/

so do you really believe it'd cover all SQL systems or just SQL Server?
All OSs on which SQL RDBMSs run or just Windows? You really have a
narrow perspective, not to mention real problems with credulousness.

In the real world most database processing (in terms of bytes of data
processed) still takes place on mainframes. Ain't no stinkin' VB[*] on
mainframes, though mainframes could be ODBC data sources if a suitable
interface were implemented.

If you work for a small firms or one with a low transaction count, then
it's likely your firm doesn't use a mainframe. If so, you're still
suffering from the limitations of your own experience.

As for the web, check out Netcraft if you haven't already. Most web
sites run under Unix-like OSs like, e.g., Amazon. Ain't no stinkin'
VB[*] on Unix-like systems, and web servers aren't ODBC data sources
(though there may be tools to treat tables on html pages as relational
tables).

So how do you explain all those banks, insurance companies, securities
traders and brokers, government agencies that use mainframes? They just
don't employ any of the 'top database people'? Guess that must also
hold true for all the companies using Solaris, Linux, [*]BSD or even
Unixware and Mac OS X as the OSs for their web servers.

Grow up!

it's like a dead issue. VB won the war.

If working in a Windows-only shop, it may seem that way.

It is 3x easier to write somethign in ADP/MDB than it is in VB; or any other
language.

Anything?! How would you use ADP/MDB to write a simulation application
to model life insurance costs for a set of individuals of different
ages and risk characteristics? How would you use ADP/MDB to determine
the risk-based capital of Citibank? How would you use ADP/MDB to
optimize lift vs drag in wing designs? How would you even use ADP/MDB
to model traffic patterns to optimize traffic signal coordination and
timing in a given geographical area?

You are SO naive! Go back to writing database backends for your time
sheet reports.

 

[Nick Hodge]

Aaron

Please explain why, in actual fact, although maybe desirable, there would be
any need to have more than 65536 rows in any analytical, financial tool.
That number of rows cannot be 'visually' charted or 'read' by a human in any
application.

Hence Excel is *not* a database and that's why I use it and use a database
for data work.

--
HTH
Nick Hodge
Microsoft MVP - Excel
Southampton, England
(e-mail address removed)

 

[hrlngrv]

Frank Kabel wrote...
....

. . . But again: There's a world outside
Windows. Please tell me how you use VB on them? (though would be nice to
have it on these platforms...) . . .

I have nothing against choice, but I doubt you'd get many *x developers
interested in using VB[*] or any BASIC dialect. Once one gets used to
the terseness of C-derived languages like Perl, PHP, Java, etc., it's
very hard to return to the klunkiness of BASIC. There's also the
syntactic obtuseness of array dereferncing and function calls with
integer arguments being lexically identical (both starting with
identifier tokens followed by parenthesized lists of integer
expressions).

FWIW, *x systems have XBasic, which is also available for Windows.

. . . And if you now argue that Windows will
replace everything else: Well this won't happen in the near future and here
as well choose the right platform for the right task

Clearly won't happen on mainframes. And there are a few too many
millions of Linux and FreeBSD users and (yes) developers to imagine
it'll ever happen on smaller systems. Definitely won't happen until
Microsoft figures out how to write secure software.

....
. . . If you can't see this difference
than you seem to be very restrictive in the choice of your tools. And that
is never a good sign.

To paraphrase the old saying, if you only know how to use a hammer,
everything looks like a nail (and you litter your responses with links
to articles in Hammer & Nail magazine).

 

[Frank Kabel]

. . . But again: There's a world outside

Windows. Please tell me how you use VB on them? (though would be
nice to have it on these platforms...) . . .

I have nothing against choice, but I doubt you'd get many *x
developers interested in using VB[*] or any BASIC dialect. Once one
gets used to the terseness of C-derived languages like Perl, PHP,
Java, etc., it's very hard to return to the klunkiness of BASIC.
There's also the syntactic obtuseness of array dereferncing and
function calls with integer arguments being lexically identical (both
starting with identifier tokens followed by parenthesized lists of
integer expressions).

Hi Harlan
now maybe a more interesting OT discussion
I agree with you regarding the syntax power, etc for the other mentioned
languages. But personally I think VB is a great tool for rapid frontend
development (prototyping or real production version). It's just very easy to
get nice looking results. But really focussing on the frontend and not the
processing, etc.
To be honest on *.nix systems I'm mainly involved in data processing
projects which do not really require a GUI So there may be already a lot
of *nix tools which are as powerful as VB* for frontend development

[...]

Clearly won't happen on mainframes. And there are a few too many
millions of Linux and FreeBSD users and (yes) developers to imagine
it'll ever happen on smaller systems. Definitely won't happen until
Microsoft figures out how to write secure software.

but at least it seems they're trying a little bit harder now.

[...]

To paraphrase the old saying, if you only know how to use a hammer,
everything looks like a nail (and you litter your responses with links
to articles in Hammer & Nail magazine).

call it a circualr reference...
Frank

 

[hrlngrv]

(e-mail address removed) wrote...
....

I just think that it is funny that all of these people get sidetracked..
developing 'solutions' in Excel.

....

There are solutions to some business problems that are best addressed
by punching number and operator keys on a calculator. It'd be foolish
to use databases instead. If you need to, consider spreadsheets the
next step up from calculators. They're still useful, and for more than
you may realize they're still more efficient than the alternatives.

re-creating the same spreadsheet, week in and week out..

If true, then that's inefficient (as already agreed). That only means
that predominantly repetitive tasks may be better automated with
databases and reporting tools.

templates' don't help-- what happens when they change??

Uh . . . maybe the same thing that happens when stored procedures
change? Maybe the same thing that happens when the reporting tool
software is upgraded but the new version has a bug that the old version
didn't.

And as I explained before, if you adopt a storage scheme in which
*only* user entries are stored in data files (which could be .XLS
files, plain text files, or even XML files) and the 'template' workbook
(stored centrally and not modified by users) reads its data from those
data files and 'saves' user entries to those data files, then aside
from newly introduced bugs nothing but good happens when templates
change.

I know this isn't the normal way spreadsheets are designed, but it's
analagous to how Excel itself works. When you save an .XLS file, Excel
doesn't embed a full copy of EXCEL.EXE in it. I just mean applying the
same approach to separating user entries from formulas and macros. IT
CAN BE DONE!

do you have to go back and 'untemplate' everything you do and push it into a
new template?

You don't understand. See above. You're laboring under the
misconception that you always have to save complete copies of the
formulas and macros along with user entries. You don't.

Even if you did, it's a useful exercise to develop workbooks that use
tables (worksheet ranges) consisting of worksheet/range addresses and
revised contents and macros that apply the revisions contained in such
tables to targetted workbooks. Batch updating of existing workbooks
isn't so difficult, well, not after the first few times you do it.

 

[beliavsky]

COBOL may be one thing, but FORTRAN will die only when netlib,
LINPACK,

EISPACK, etc. are translated into other languages. But if FORTRAN code
can be compiled into reentrant libraries (which it can on mainframe,
Unix-like, Windows and presumably Mac (JE - confirmation?) platforms),
why bother? FORTRAN will be around for a long time to come.

The next version of LAPACK, which supersedes LINPACK and EISPACK, will
still be written in FORTRAN 77, because the authors believe that
translating it to another language would just be too much work. This
was mentioned in a long, recent Usenet discussion with title "clapack".

I think Fortran deserves to live not just because of all the legacy
code but on it own merits as a language. Fortran 90 and later versions
fixed the problems with FORTRAN 77 and introduced array operations and
free source format among other things. Fortran 90 is like a compiled
version of MATLAB, a very sucessful product.

Intel has seriously entered the Fortran compiler market only in the
last few years, and they would not have done so if they thought it were
dead.

VBA is IMO a simple, well designed language for novice programmers, and
it's closer to Fortran than C++ or Java in style.

 

[hrlngrv]

(e-mail address removed) wrote...

Show me riduculous when I see a dozen people making $60k on this single
floor in this single company.. where all they do is type stuff in

Excel.

I believe you've already mentioned you work at SAFECO. I'd be willing
to bet there are a few actuaries still working for SAFECO, and most if
not all of them would use Excel most of the time. If they were filling
out, say, California prior approval rate filing forms, then you are
seriously deluded in believing that you could replicate the
spreadsheets they're likely using without resorting to procedural
coding.

There'd also be investment management and tax departments, and while
they may use databases to store and retrieve information about
securities, real properties and underwriting data, their real work of
managing investment income and tax liabilities wouldn't involve
databases. For that matter, if SAFECO is like most other US P/C
insurance companies, its IBNR reserves (a large portion if not the bulk
of its total liabilities) is unlikely to be stored in any database
other than as direct and net total figures in whatever system generates
the statutory annual statements and GAAP financials.

As I've mentioned before, subject matter knowledge is important. You
might want to consider that it'd be quite difficult for SAFECO to
replace most of those $60K-a-year Excel users, but it'd take only a few
days to replace a database generalist like you with as little
understanding of what goes on in a P/C insurance company.

That is what I call ridiculous.

Because you don't understand their relative value to your employer
compared to your own. I suppose I should pity you.

There is a better way; it came out back in the 70s-- Excel shoudln't be used
for reporting out of a database.. It just isn't the best tool for the

job.

For regular, repetitive reporting, agreed.

It isn't POWERFUL enough to do anythign with SQL Server..

....

You're back on thin ice. If the database and reporting tools on their
own or nearly so can generate entire reports, then they'd be the best
tool. On the other hand, if many calculations are needed, the database
may only be best suited as the storage subsystem. You're seriously
deluded if you believe any database handles all calculation more
efficiently than spreadsheets. Given enough views and udfs, databases
may be able to perform the same calculations, but it's likely they'd do
so less efficiently.

Rule of thumb (not necessarily *always* true, but usually true): large
amounts of data, few simple calculations -> database better than
spreadsheets; small amounts of data, many and/or complicated
calculations -> spreadsheets better than databases.

Go on, *PROVE* me wrong. Show us how you'd use Access to write an
amortization table. Why haven't you done so already?

64k records, i poop 64k records at a time

Well, that explains a lot.

 

[Guest]

haha yeah... I just know that out of all of the beancounters in the whole
wide world-- that there isn't a single one of you that is doing your job as
efficiently as possible.

wake up to this phenomenon called RDBMS

It will simplify your life

You don't have to tab between sheets to store more than 64k records LoL

 

[Guest]

just because some crazy beancounters use Excel-- it doesn't make it right


In germany in the 1930's-- there was the same sort of mentality-- do it
because everyone else is doing it.

It is dangerous to GROUPTHINK just because someone else does it.

And I KNOW FOR A FACT THAT I CAN MAKE A REPORT THAT DOES ALL SORTS OF MESSED
UP CALCULATIONS... I MEAN-- IS THERE A SINGLE THING I CAN'T DO IN SQL SERVER
OR ACCESS THAT I CAN DO IN Excel?

With batch processing of stored procs-- I can, and I do-- throw around some
huge numbers like you woudln't believe.

You can script out this stuff-- so that you can have your jobs run at night.

Can you beancounters have your weekly and monthly reports run at night?

HAHAHAHHAHA only if you're sitting there, typing values and cuttign and
pasting...

I move more numbers around between 2am and 3am than most of you guys do in
your whole lives.

You guys need to grow up.. I mean XLS is _SOOOOOOOOOO_ 1995...

 

[Guest]

people use Excel for a database all the time... it is a tragedy.. an
absolute tragedy-- that you guys are 'scared of databases' and 'scared to be
seen as a programmer' and 'scared to use the most popular database in the
world-- _ACCESS_'

At my last contract at MSN, we had an XLS to keep track of a project plan,
and an XLS to keep track of which servers were in which stage of deployment.

We used Excel to keep track of which projects we were working on.

We used Excel to keep track of which bugs we were trying to fix.

It was friggin ridiculous. Take this program and SHOVE IT!!!!

The deptartment wasn't EFFICENT because of the fact that we were always
emailing spreadsheets around..

Sharepoint doesn't solve the problem-- it makes it worse

ABANDON SHIP ABANDON SHIP

EXCEL IS A DISEASE, A DEAD-END STREET.

This is your brain on Excel


XXXX
XXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXx


(that is my representation of a pile of poop-- what you beancounters will be
eating when we kick you out of a job)

 

[JE McGimpsey]

people use Excel for a database all the time... it is a tragedy.. an
absolute tragedy-- that you guys are 'scared of databases' and 'scared to be
seen as a programmer' and 'scared to use the most popular database in the
world-- _ACCESS_'

<Yawn>

A couple of days ago you were a slightly interesting troll who brought
up one or two interesting points, and I opined that I hoped you stuck
around.

Now you're just being a vulgar, shrill, obtuse and immature troll, whose
posts, should you make any, I won't miss.

<PLONK!>

 

[hrlngrv]

(e-mail address removed) wrote...

haha yeah... I just know that out of all of the beancounters in the whole
wide world-- that there isn't a single one of you that is doing your job as
efficiently as possible.

wake up to this phenomenon called RDBMS

It will simplify your life

You don't have to tab between sheets to store more than 64k records

LoL

It's possible to misuse Excel. It's possible to misuse RDBMSs.

If one needs or would benefit significantly from an RDBMS, one should
use one. If trying to use an RDBMS for a calculation-driven application
would be a monumental waste of time, one shouldn't. It's really simple.

If you're doing something as simple as generating repetitive reports,
then by all means *you* go on an use a database. If I had a job in
which I had to do that, I'd want to use a database too. That doesn't
mean everyone would, and it doesn't mean every report in every company
is produces entirely or almost so from easily accessed RDBMSs. If the
information that needs to appear in some report doesn't come from any
in-house database, guess what tool makes little or no sense for
generating that report?

 

[hrlngrv]

(e-mail address removed) wrote...

just because some crazy beancounters use Excel-- it doesn't make it

right

Just because you have absolutely no clue what anyone is doing who sits
further away than 2 desks from you, you somehow know the best way for
them to do their jobs. Damn, with a mind like that why aren't you the
CEO?

Do you have any idea what other people are really doing outside the
department in which you work? Do you have any idea how to read your
company's financial statements?

In germany in the 1930's-- there was the same sort of mentality-- do it
because everyone else is doing it.

....

Hurray! We've reached the first stages of the end of a pontless thread!
The first reference (oblique though it is) to Nazi Germany. This is
generally taken as an indication you ran out of anything useful or
interesting to write 6 or so response levels previously and it's taken
you this long to dream up the idea that you can cover your butt with
bizarre historical analogies.

And I KNOW FOR A FACT THAT I CAN MAKE A REPORT THAT DOES ALL SORTS OF MESSED
UP CALCULATIONS... I MEAN-- IS THERE A SINGLE THING I CAN'T DO IN SQL SERVER
OR ACCESS THAT I CAN DO IN Excel?

Dunno. As yet you haven't proven you could even put together a simple
amortization table. Until you show some ability to do anything useful
(even as tenuously so as an amortization table), I'm justified in
believing you only possess the ability to rant & rave.

But if amortiation tables are too mundane for you, by all means show us
how you'd calculate estimators and standard errors for linear models. I
think UPenn/Wharton still publish some data you could use if you don't
know how to make some up on your own.

With batch processing of stored procs-- I can, and I do-- throw around some
huge numbers like you woudln't believe.

You may throw around huge numbers and even huge numbers of numbers, but
do you do anything with them more complicated than summing, counting,
averaging or the occasional min or max? SUM, COUNT, AVERAGE, MIN, MAX
and other univariate descriptive statistics are simple calculations
(relatively speaking, and despite the fact that Microsoft took a very
long time to make Excel's VAR and STDEV work robustly). Do you even
know how to calculate, say, maximum likelihood estimator for the
parameter of an exponential distribution given a series of waiting
times?

Can you beancounters have your weekly and monthly reports run at

night?
....

This may come as news to you. Senior management generally relies more
on the one or two page reports put together probably using Excel than
the hundred or thousand page reports that need to be generated over
night. Perhaps you confuse the volume of paper consumed with the
importance of the report.

 

[Bill Sharpe]

It must be very easy to create an amortization table in Access.
Searching Access help online gives no results for "amortization."
Obviously it's a trivial task, needing no help entry.

Why don't you show us how it's done, Aaron?

Bill Sharpe

you guys are crazy, i can create that in a database.. just as easily as
you
can create it in a spreadsheet.

Are you retarded?

Do you really think that I can't store that information in a table?

Also-- if you're talking about the whole pivot ability.. There is a
wizard
to pivot this and in SQL2005; pivot and unpivot is a reality.

Are you really too retarded to realize that i can put this in a table
just
as easily as you can put it in a spreadsheet?

And you're seriously bitching about how this is 'too complex'

hahahahahhaa

grow up and learn SQL kid

 

[Guest]

WTF is a 'calculation-driven application'

Are you saying I don't do calculations? The breadth of calculations that
databases can do-- especially when you consider temporary tables-- it is
sickening to me to think that you have the audacity to think that you have a
'calculation driven application' and i dont.

your calculation driven application is a waste of time, i can automate your
job in my sleep.

You just have no appreciation for databases; and thats why you are roadkill

Databases trump Spreadsheets.

You guys need to get a real career.

 

[Guest]

you are the biggest idiot i've ever met in my life.

all it is is a query.. joined to itself a whole bunch of times...
technically an N number of times.. aka a crosstab (or matrix for you trendy
types)

if you are trying to make a pivotTable based on employee hours-- i couldnt'
figure it out, so i went into Excels' help and I typed in 'employee hours'
and nothing showed up in excels' help.. does this mean that it's impossible
to make a pivot table on employee hours in Excel?

if i look in word for 'resume for aaron kempf' and nothing shows up; does
this mean that word can't make a resume for aaron kempf?

hahahahahahahahah

searching in Access help for 'amortization'.. hahahahhaha where do you guys
get made?

it didnt occur to you to try this in google?

or you can ask on a newsgroup?

there are THOUSANDS of newsgroups about databases.

there are thousands of companies that make and provide databases.

do you know why Oracle doesn't come out with a spreadsheet? Do you know why
IBM doesn't come out with a spreadsheet program??

BECAUSE IT IS OBSOLETE!!!!

is there a bootcamp for 'how to be a jackass beancounter and re-create the
same report by hand every week'?

hahaha where you gonna go when you hit the 64k limit buddy?

 

[Guest]

VAR and STDEV is also in SQL Server.. the things that you guys don't
understand is that ANY FUNCTION that is in Excel is also in MDX-- they share
the same codebase..

MDX is _THE_ spreadsheet language that you do on the database side.

It came out 5 or 6 years ago; and it's changing the world.

The difference is that you can either put your business logic in a
spreadsheet and copy if every month..

or you can automate and catalog the MDX and presto-chango-- you don't need
to make the same report every week.

I can put together an amortization table.. all it is is a self join (in
RDBMS) or a pretty PivotList via OLAP (much more powerful); a bunch of
times.. not that complex. I would prefer to do it in olap

OLAP makes it a lot easier than traditional database queries... We can make
it in a pretty crosstab format so that you guys can export it from the
database and put it in your spreadsheet; and then you can pull it out of a
database, you make it pretty; waste a lot of time.. and then you recreate
the same report next week.

don't you guys feel hollow inside?

don't you guys see that there MIGHT be a better way?

compound interest-- this kindof stuff is easy to do in a database.. this
stuff is simple simple stuff.

Get a clue, spreadsheets are dead.. MDX and OLAP or SQL Server can do
anything you're doing.. but you guys are too egocentric to drop this
obsolete program and wake up to the 21st century.

I just want to make sure that every one of you understand that there is a
war going on in IT departments; and this is a battle against Elitist
obsolete management; and database professionals that are going to automate
you out of a job.

I hope that you guys diversify and expand your horizons.

aaron

 

[Guest]

klunkiness of VB

hahahahahha

it's got _EVERYTHIGN_ those other languages have and then some.

WTF do you mean by klunkiness??

it has better errorhandling.. it has better _PERFORMANCE_ than other
languages out there.

VB has momentum. VB has marketshare.

it is ridiculous to even consider other languages.

Frank Kabel wrote...
...

. . . But again: There's a world outside
Windows. Please tell me how you use VB on them? (though would be nice to
have it on these platforms...) . . .

I have nothing against choice, but I doubt you'd get many *x developers
interested in using VB[*] or any BASIC dialect. Once one gets used to
the terseness of C-derived languages like Perl, PHP, Java, etc., it's
very hard to return to the klunkiness of BASIC. There's also the
syntactic obtuseness of array dereferncing and function calls with
integer arguments being lexically identical (both starting with
identifier tokens followed by parenthesized lists of integer
expressions).

FWIW, *x systems have XBasic, which is also available for Windows.

. . . And if you now argue that Windows will
replace everything else: Well this won't happen in the near future and here
as well choose the right platform for the right task

Clearly won't happen on mainframes. And there are a few too many
millions of Linux and FreeBSD users and (yes) developers to imagine
it'll ever happen on smaller systems. Definitely won't happen until
Microsoft figures out how to write secure software.

...
. . . If you can't see this difference
than you seem to be very restrictive in the choice of your tools. And that
is never a good sign.

To paraphrase the old saying, if you only know how to use a hammer,
everything looks like a nail (and you litter your responses with links
to articles in Hammer & Nail magazine).

 

[Guest]

I don't disagree that PHP is the bomb.. it has very impressive performance
at least.. i just dont' think that there is a lot of room for 20 different
programming languages out there.. VB has the Microsoft developers

VB has the marketshare, VB has the right tools.

It is ridiculous that talk about other languages.

The other languages that you guys need to be concerned with are SQL and MDX.

Those are the important languages.

-Aaron

. . . But again: There's a world outside
Windows. Please tell me how you use VB on them? (though would be
nice to have it on these platforms...) . . .

I have nothing against choice, but I doubt you'd get many *x
developers interested in using VB[*] or any BASIC dialect. Once one
gets used to the terseness of C-derived languages like Perl, PHP,
Java, etc., it's very hard to return to the klunkiness of BASIC.
There's also the syntactic obtuseness of array dereferncing and
function calls with integer arguments being lexically identical (both
starting with identifier tokens followed by parenthesized lists of
integer expressions).

Hi Harlan
now maybe a more interesting OT discussion
I agree with you regarding the syntax power, etc for the other mentioned
languages. But personally I think VB is a great tool for rapid frontend
development (prototyping or real production version). It's just very easy to
get nice looking results. But really focussing on the frontend and not the
processing, etc.
To be honest on *.nix systems I'm mainly involved in data processing
projects which do not really require a GUI So there may be already a lot
of *nix tools which are as powerful as VB* for frontend development

[...]

Clearly won't happen on mainframes. And there are a few too many
millions of Linux and FreeBSD users and (yes) developers to imagine
it'll ever happen on smaller systems. Definitely won't happen until
Microsoft figures out how to write secure software.

but at least it seems they're trying a little bit harder now.

[...]

To paraphrase the old saying, if you only know how to use a hammer,
everything looks like a nail (and you litter your responses with links
to articles in Hammer & Nail magazine).

call it a circualr reference...
Frank

 

[Guest]

the right platforms?

there is only one platform.

it is called Windows.

TPC.org-- until just recently when Oracle 10g (and also then Power5
processors) came out; Microsoft SQL Server had every performance record..

When Sun comes out with a 16-way Opteron and a 32-way Opteron; I am pretty
sure that Windows and SQL Server will take the performance crown again..

And what are you talking about 'really large databases'?? LoL

That type of attitude is out of date.

i worked on a 5tb database at Microsoft; and I never had a single report
that took longer than a second.

We had 150gb of data per day. We scrubbed the data; denormalized it and
stored slices of it.. We obviously couldn't afford to keep 1.2 TB of raw
data every week.. But this db ran like a charm!!!

That is the power of OLAP.