While most languages are LL(k) for some k, most
grammars are not, and require some massaging to get
into a form which LL parsers will accept. The massaged
version is invariably not the "most preferred" way to
specify the language. In many cases, a compiler compiler
(such as ANTLR) can do the massaging automatically, but
this is often not the case.
Both ISO and ARM C++'s grammars, in particular, are
inherently ambiguous and require semantic
disambiguation no matter what you do.
Most of the responses are missing the point, I think.
Step outside the box for a moment...
When you write software, you have an intended
interpretation, namely, what you intend the program
to do based on what you meant to write. The compiler, on
the other hand, has its own interpretation of your program,
based on what you actually wrote.
Debugging is the process of finding discrepancies
between those two interpretations.
Understanding this reveals what directions debugging tools
should go. Current tools put the programmer in the driving
seat, trying to understand how the system has interpreted
their program. The next generation will put the system
in the driving seat, asking the programmer what they meant
that operation should do. Like with a human teddy bear,
the act of explaining it to the system might even clarify
things enough in the programmer's mind that the problem may
become obvious. Or, we may end up in a kind of "pair
debugging" situation where the system becomes a code
reviewer.
Something amusing: In Commonwealth English, the term
"solicitor" refers to a lawyer. When I first visited the
US, the airport had these annoucements about how you did not
have to give money to solicitors, and the airport did not
encourage their activities. I found this funny.
I'm not sure why constants in interfaces are
so important, but my guess it is the language's answer to
some whiny C/C++ programmer on the design team who couldn't
express his favorite idiom without it.
It's because Java doesn't have enumerated types, which are
often part of an object's interface.
Sure you can do without enums (e.g. by using an ABC and
deriving the relevant constants), but you wouldn't want to.
I know you meant it as a joke, but for some applications
(squid springs to mind, plus a few specialist web cache-like
applications that I've written), it's precisely what you
need.
All data can fit neatly into the relational
model, provided one defines the domains and normalise.
Say what?
Any data can be shoehorned into a relational model if you
use enough IDs. For any sufficiently complex model, there
comes a point when it goes way beyond "neat".
A few examples that I have worked with spring to mind,
most of which would take too long to explain. Consider,
however, manipulating a directed acyclic (or, indeed,
cyclic) graph where you need to query on "reachability" and
propagate information around the network.
A relational setup for this would got pretty unwieldy pretty
fast.
Just make text a supported data type. In
fact, even SQL databases can do that.
I'm yet to see an SQL database which can handle multiple
terabytes of textual data, pulling in documents and full-text
indexing them in "real time". (Disclaimer: I get paid to
work on a product which can do precisely this, amongst
many other things.) For this, you need a database optimised
for storing and indexing text (e.g. SGML, XML).
I think we might be talking about different things when
we say "XML databases", BTW. I'm talking about databases
which store and index XML data (i.e. XML is a basic data
type), possibly in addition to other kinds of data. I think
you're talking about databases where XML is the record
model too. Sorry about the confusion.
I do take your point about DBAs worrying about the
physical model(s) and application developers working on a
more abstract model of the data, but unfortunately I've
never worked under those conditions. Small to medium-sized
organisations working under budgetary constraints can't
afford enough DBAs who have domain-specific knowledge about
all of the individual problems that the enterprise
applications are trying to solve. A physical database which
follows the conceptual model of the data closely is a big
boon here, as there are far fewer surprises.
There is no OO data model to adhere to [...]
Guess you haven't heard of
ODMG.
It very much exists, however most OODBMS vendors
support it incompletely.
I agree that relational databases are the best
solution for most problems -- that's why they're the
backbones of most apps these days.
More correctly, they're the least worst solution
for most problems. The reasons why they're the backbones of
most apps these days are far more likely to be some
combination of:
It's a legacy system.
It's all the designers know. (Everyone gets taught
relational databases/SQL these days, even visual basic
script kiddies.)
FUD from a big DBMS vendor. Why would you trust your
data with anyone but Oracle, after all?
We already have a licence for Oracle/SQL
Server/DB2/whatever.
Summarising several other replies and
adding my own biasses...
The overwhelming majority of SQL-based DBMSes are not
true relational databases.
A lot of data (probably "most") does not fit neatly into
the relational model.
XML-driven databases are close to perfect if you're
storing and indexing documents. In particular, trying to
index text using a relational system is pretty close to the
dictionary definition of "insane". OTOH, non-text data and
XML can often be a bad fit.
Lazy programmers are a problem no matter what you do.
Forcing them to stay on their toes by giving them a system
they have to fight with is no answer.
OODBMSes have a lot of promise, but there are no
standards which are adhered to. Expect vendor lock-in if you
go down this path.
Summary: All data storage solutions suck. For your
specific application, there will be one or two which suck
the least. That's why they pay you.
These "idiots", as you call them, are just doing the job
that Congress set for them. They are not legally allowed to
do otherwise.
Don't shoot the messenger.
Re:It makes sense
on
Google vs. Evil
·
· Score: 3, Insightful
I don't claim to attribute anything to religion.
Here's what you said:
Nothing in the world makes people do more insane and idiotic things
[...]
Which part did I misinterpret?
Religion is no different than any other philosophy or,
"predating the modern age" as you say, any other societal
norm. People do insane and idiotic things. Religion
doesn't make anyone this way, they just are.
Actually it's the fact that the various religions seem more intent on teaching people to do as they're told than teaching them to think for themselves. That's why religious people are so easy to
manipulate.
Sorry to burst your bubble, but everyone is taught to do as
they're told, by their parents, by the education system, by
politicians, by advertisers, by employers, by the news
media, by people who write books and so on and so forth.
Everyone is discouraged from thinking for
themselves. Everyone is easy to manipulate. It has
always been this way and always will be this way. It's not
a conspiracy, it's just the way the system works.
And if you can't see it, you've been sucked into it too.
Yes, and apparently most of them are into Dragonball.
This explains Lycos' target demographic.
Re:It makes sense
on
Google vs. Evil
·
· Score: 3, Insightful
Yeah, yeah, yeah...
Almost every atrocity which you would attribute to
religion is in fact traceable to greed and/or politics. This
is partly a function of poor separation of church and state.
If church and state are blurred, the church gets blamed
for everything the state does.
Ignoring the confrontational rhetoric for a moment, I think you've hit on exactly the issue here. The big problem is changing the status quo, whatever it is in your neck of the
woods.
Disarming the United States would have exactly the same
effect as arming a currently unarmed country (e.g. Australia), or introducing unregistered high-powered ammunition in Switzerland. It would create upheaval.
Now getting back to that confrontational attitude of yours. I hate to break this to you, but it fits the NRA stereotype perfectly. If you want to win more people over to the anti gun control side, you might want to make it look a lot less like gun owners are trying to pick a fight.
You'd want to arm half of the houses with each kind of sign and disarm the other half.
You'd have to repeat the experiment in several kinds of neighbourhood. One in (say) Texas, one in Vancouver, one in Melbourne (Australia, not Florida), one in Geneva and so on.
If you did it around where I live, it'd make no difference. (I live at the end of a cul-de-sac in an outer
suburb in one of the lowest crime cities in the country.) YMMV
I'd love to see evidence of a functional (or
any other) program that can out perform the naive C
equivalent.
This is a C++ program which out-performs the naive C
equivalent, at least on one platform. I don't draw any
conclusions from this other than that there is evidence.
Intuitively, though, languages which support compile-time
specialisation of polymorphic code is always going to beat
the naive C equivalent (probably based on callbacks) ll
other things being equal. In the case of the comparison
between C and C++, they almost certainly are equal, as most
C compilers are really C++ compilers run (or compiled) with
C++ turned off. Similarly, chances are good that your C
library and your C++ library were written by the same
people.
As a matter of interest, how do you combine cleanup and
exceptions in C? I mean if you throw an exception, you want
this memory deallocated and this file closed and this lock
released and so on.
I can think of a few ways to do it, but none of them are
anywhere near "natural-looking".
Do you have any references?
(No, this is not a pro-C++ troll. I'm genuinely curious.)
Links man, come on! This is Slashdot, you
can't just make wild assertions without backing them up
with facts.
You're new around here, aren't you?
Since you asked, though, the first thing to realise that
you may well have written a program in a high-level language
which can way outperform the naive C equivalent yourself.
Ever used yacc (or bison)? It's a high-level
language compiled to C, after all. I defy you to write a
naive (the "naive" part is important) LALR(1) parser in C
yourself which outperforms those generated by yacc
and related tools.
The functional language Sisal
beats High Performance Fortran on numerical simulations. (Note: This
is an older paper; Sisal has changed a bit since then.)
Still, this is not the real benefit of high-level
languages. The point is that in many situations, you gain a
lot without paying too much. There's always C and assembly
language below a high-level language if you find you really
need it. If you don't, or for those part of an application
where you don't, you get rapid development, higher
robustness and better maintainability, and that's where you
win.
Slashdot Mirror
The quote from Terrence Parr is misleading.
While most languages are LL(k) for some k, most grammars are not, and require some massaging to get into a form which LL parsers will accept. The massaged version is invariably not the "most preferred" way to specify the language. In many cases, a compiler compiler (such as ANTLR) can do the massaging automatically, but this is often not the case.
Both ISO and ARM C++'s grammars, in particular, are inherently ambiguous and require semantic disambiguation no matter what you do.
Here, try some botulism for starters, perhaps with a smallpox chaser.
Most of the responses are missing the point, I think. Step outside the box for a moment...
When you write software, you have an intended interpretation, namely, what you intend the program to do based on what you meant to write. The compiler, on the other hand, has its own interpretation of your program, based on what you actually wrote. Debugging is the process of finding discrepancies between those two interpretations.
Understanding this reveals what directions debugging tools should go. Current tools put the programmer in the driving seat, trying to understand how the system has interpreted their program. The next generation will put the system in the driving seat, asking the programmer what they meant that operation should do. Like with a human teddy bear, the act of explaining it to the system might even clarify things enough in the programmer's mind that the problem may become obvious. Or, we may end up in a kind of "pair debugging" situation where the system becomes a code reviewer.
Something amusing: In Commonwealth English, the term "solicitor" refers to a lawyer. When I first visited the US, the airport had these annoucements about how you did not have to give money to solicitors, and the airport did not encourage their activities. I found this funny.
It's because Java doesn't have enumerated types, which are often part of an object's interface.
Sure you can do without enums (e.g. by using an ABC and deriving the relevant constants), but you wouldn't want to.
I know you meant it as a joke, but for some applications (squid springs to mind, plus a few specialist web cache-like applications that I've written), it's precisely what you need.
Say what?
Any data can be shoehorned into a relational model if you use enough IDs. For any sufficiently complex model, there comes a point when it goes way beyond "neat".
A few examples that I have worked with spring to mind, most of which would take too long to explain. Consider, however, manipulating a directed acyclic (or, indeed, cyclic) graph where you need to query on "reachability" and propagate information around the network. A relational setup for this would got pretty unwieldy pretty fast.
I'm yet to see an SQL database which can handle multiple terabytes of textual data, pulling in documents and full-text indexing them in "real time". (Disclaimer: I get paid to work on a product which can do precisely this, amongst many other things.) For this, you need a database optimised for storing and indexing text (e.g. SGML, XML).
I think we might be talking about different things when we say "XML databases", BTW. I'm talking about databases which store and index XML data (i.e. XML is a basic data type), possibly in addition to other kinds of data. I think you're talking about databases where XML is the record model too. Sorry about the confusion.
I do take your point about DBAs worrying about the physical model(s) and application developers working on a more abstract model of the data, but unfortunately I've never worked under those conditions. Small to medium-sized organisations working under budgetary constraints can't afford enough DBAs who have domain-specific knowledge about all of the individual problems that the enterprise applications are trying to solve. A physical database which follows the conceptual model of the data closely is a big boon here, as there are far fewer surprises.
Guess you haven't heard of ODMG. It very much exists, however most OODBMS vendors support it incompletely.
More correctly, they're the least worst solution for most problems. The reasons why they're the backbones of most apps these days are far more likely to be some combination of:
Flamebait time!
Summarising several other replies and adding my own biasses...
Summary: All data storage solutions suck. For your specific application, there will be one or two which suck the least. That's why they pay you.
It's Daikatana, right?
Actually, it could arguably be an improvement.
Ah, you've never really heard Elvis until you've heard him in the original Klingon.
Yes and no. In the dictionary I consulted, "free disk space" and "free time" are distinct uses of "free". In summary:
This comment is free as in 97% Fat Free.
Actually, the fourth, which has been going around for a longtime, is free as in free time.
Free as in Tibet!
These "idiots", as you call them, are just doing the job that Congress set for them. They are not legally allowed to do otherwise.
Don't shoot the messenger.
Here's what you said:
Which part did I misinterpret?
Religion is no different than any other philosophy or, "predating the modern age" as you say, any other societal norm. People do insane and idiotic things. Religion doesn't make anyone this way, they just are.
Sorry to burst your bubble, but everyone is taught to do as they're told, by their parents, by the education system, by politicians, by advertisers, by employers, by the news media, by people who write books and so on and so forth.
Everyone is discouraged from thinking for themselves. Everyone is easy to manipulate. It has always been this way and always will be this way. It's not a conspiracy, it's just the way the system works.
And if you can't see it, you've been sucked into it too.
Bad idea. Half the mathematics papers the 20th century would have the following author list:
Yes, and apparently most of them are into Dragonball. This explains Lycos' target demographic.
Yeah, yeah, yeah...
Almost every atrocity which you would attribute to religion is in fact traceable to greed and/or politics. This is partly a function of poor separation of church and state. If church and state are blurred, the church gets blamed for everything the state does.
Guns don't stop criminals, people stop criminals. Just like how guns don't protect freedom, people protect freedom.
Ignoring the confrontational rhetoric for a moment, I think you've hit on exactly the issue here. The big problem is changing the status quo, whatever it is in your neck of the woods. Disarming the United States would have exactly the same effect as arming a currently unarmed country (e.g. Australia), or introducing unregistered high-powered ammunition in Switzerland. It would create upheaval.
Now getting back to that confrontational attitude of yours. I hate to break this to you, but it fits the NRA stereotype perfectly. If you want to win more people over to the anti gun control side, you might want to make it look a lot less like gun owners are trying to pick a fight.
To be a fair comparison:
If you did it around where I live, it'd make no difference. (I live at the end of a cul-de-sac in an outer suburb in one of the lowest crime cities in the country.) YMMV
While that's true, recall what the challenge was:
This is a C++ program which out-performs the naive C equivalent, at least on one platform. I don't draw any conclusions from this other than that there is evidence.
Intuitively, though, languages which support compile-time specialisation of polymorphic code is always going to beat the naive C equivalent (probably based on callbacks) ll other things being equal. In the case of the comparison between C and C++, they almost certainly are equal, as most C compilers are really C++ compilers run (or compiled) with C++ turned off. Similarly, chances are good that your C library and your C++ library were written by the same people.
As a matter of interest, how do you combine cleanup and exceptions in C? I mean if you throw an exception, you want this memory deallocated and this file closed and this lock released and so on.
I can think of a few ways to do it, but none of them are anywhere near "natural-looking".
Do you have any references?
(No, this is not a pro-C++ troll. I'm genuinely curious.)
You're new around here, aren't you?
Since you asked, though, the first thing to realise that you may well have written a program in a high-level language which can way outperform the naive C equivalent yourself. Ever used yacc (or bison)? It's a high-level language compiled to C, after all. I defy you to write a naive (the "naive" part is important) LALR(1) parser in C yourself which outperforms those generated by yacc and related tools.
Slightly less facetious examples:
Still, this is not the real benefit of high-level languages. The point is that in many situations, you gain a lot without paying too much. There's always C and assembly language below a high-level language if you find you really need it. If you don't, or for those part of an application where you don't, you get rapid development, higher robustness and better maintainability, and that's where you win.