| View previous topic :: View next topic |
| Author |
Message |
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3150
|
 Posted: Wed Feb 10, 2016 4:48 pm Post subject: |
 |
|
| Quote: | | 5 programming languages (c,c++,c#,sql,python) |
SQL is not a programming language and the C family are so close to each other it really makes total of 2, with python being the second one.
| Quote: | | So I'm really excited about making custom firmware,embedded systems,remote systems,custom kernals and programming it all to do whatever I need! |
So am I | Quote: | | I'm not sure how realistic this is though |
Not very realistic. We're like 50 years late to the show. I can't say I'm very sorry about it though. There's enough fun with high level stuff I hardly care for the low level one, as long as it works. |
|
| Back to top |
|
 |
Otherworlds
n00b
Joined: 08 Feb 2016
Posts: 15
|
| Posted: Wed Feb 10, 2016 5:55 pm Post subject: |
|
|
[quote="szatox"] | Quote: | | 5 programming languages (c,c++,c#,sql,python) |
SQL is not a programming language and the C family are so close to each other it really makes total of 2, with python being the second one.
| Quote: | | So I'm really excited about making custom firmware,embedded systems,remote systems,custom kernals and programming it all to do whatever I need! |
So am I | Quote: | | I'm not sure how realistic this is though |
Not very realistic. We're like 50 years late to the show. I can't say I'm very sorry about it though. There's enough fun with high level stuff I hardly care for the low level one, as long as it works.[/quote
Something that inspired me to want to understand the kernel is by calling kernel code with the tools the kernel itself provides such as Strace,Perf and Ftrace... These allow you to debug the kernel in a way to make it easy to understand.and even write your own mini OS. Strace allows you see system calls (A OS's API) such as "what data am I sending to google", "where are my log files","what ssh command is my Ruby program running" Then Ftrace allows you to track kernel functions, and with Perf you can track L1 cache misses. Basically the kernel does tons of stuff but the programs tell it what to do using system calls which you can see with the tools..I know this from a YouTube video, but pretty sure it's accurate..
_________________
Magic Fly - Space |
|
| Back to top |
|
|
Irre
Guru
Joined: 09 Nov 2013
Posts: 434
Location: Stockholm
|
| Posted: Wed Feb 10, 2016 8:57 pm Post subject: |
|
|
| szatox wrote: | | SQL is not a programming language |
SQL = Structured Query Language  |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Wed Feb 10, 2016 9:16 pm Post subject: |
|
|
| Irre wrote: | | szatox wrote: | | SQL is not a programming language |
SQL = Structured Query Language |
Is SQL a legitimate programming language?
I can remember writing some very long SQL triggers full of conditional statements back in the early '90s. It may not be a general purpose programming language, but it's a programming language nonetheless.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
pilla
Bodhisattva
Joined: 07 Aug 2002
Posts: 7729
Location: Underworld
|
| Posted: Wed Feb 10, 2016 11:35 pm Post subject: |
|
|
Isn't PostScript Turing Complete?
_________________
"I'm just very selective about the reality I choose to accept." -- Calvin |
|
| Back to top |
|
|
eccerr0r
Watchman
Joined: 01 Jul 2004
Posts: 9691
Location: almost Mile High in the USA
|
| Posted: Thu Feb 11, 2016 12:16 am Post subject: |
|
|
Yes, I heard postscript is turing complete.
Then again some people claim html5 with CSS is also turing complete.
Then the other issue: not all variants of SQL is turing complete.
But a language is a language, does it need to be turing complete? Is English turing complete?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching? |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Thu Feb 11, 2016 4:34 am Post subject: |
|
|
| szatox wrote: | | SQL is not a programming language and the C family are so close to each other it really makes total of 2, with python being the second one. |
At least with regard to certain points therein, opinions differ.
| pilla wrote: | | Isn't PostScript Turing Complete? |
Yes. |
|
| Back to top |
|
|
pilla
Bodhisattva
Joined: 07 Aug 2002
Posts: 7729
Location: Underworld
|
| Posted: Thu Feb 11, 2016 11:57 am Post subject: |
|
|
| desultory wrote: | | szatox wrote: | | SQL is not a programming language and the C family are so close to each other it really makes total of 2, with python being the second one. |
At least with regard to certain points therein, opinions differ.
| pilla wrote: | | Isn't PostScript Turing Complete? |
Yes. |
Shouldn't click the first link.....
_________________
"I'm just very selective about the reality I choose to accept." -- Calvin |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Thu Feb 11, 2016 6:09 pm Post subject: |
|
|
A programming language need not be turing complete to be a programming language. A programming language certainly need not be turing complete to be a useful language.
Turing completeness means, loosely, that a language can emulate another turing complete language. Which means English is turing complete because it can be used to describe the features of and behavior of pretty much any known computer language.
The argument here IMO centers more around whether sql is a general purpose language. It's not.
The benefit of a general purpose language (c, c++, java, basic, etc) is that it can be used to tackle almost any problem.
The benefit of a special purpose language (sql, lisp, etc) is that they are much better than at what they do than any general purpose language. Meaning the programmer can solve the problem faster using a special purpose language than they could with a general purpose language. Since SQL is the target of everyone's angst, let's use that.
It's easier and more clear to use "select * from Customers" than it is to build a nested structure, filling in names and data types, and sending that off to an ODBC API connected to database server. The nested structures to an odbc api might be more specific, but will probably also be more fragile with respect to unexpected database structure changes.
Surely there are other programmers in this discussion who actually make their living by programming computers in conjunction with databases. It's typical to write in whatever language works best for you, and then use some sort of sql dialect to communicate with the database. There are some pretty nice interfaces which don't exactly count as sql, but they tend to be language-specific. |
|
| Back to top |
|
|
pilla
Bodhisattva
Joined: 07 Aug 2002
Posts: 7729
Location: Underworld
|
| Posted: Thu Feb 11, 2016 10:28 pm Post subject: |
|
|
| 1clue wrote: |
Turing completeness means, loosely, that a language can emulate another turing complete language. Which means English is turing complete because it can be used to describe the features of and behavior of pretty much any known computer language.
|
I don't think it applies to English (nor other non-programming languages), as by definition it requires computability. Maybe you can say that a human being is Turing complete, because it can interpret English in a way to emulate a Turing machine, but English does not seem well defined enough to be computable by itself.
_________________
"I'm just very selective about the reality I choose to accept." -- Calvin |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Thu Feb 11, 2016 11:33 pm Post subject: |
|
|
| pilla wrote: | | English does not seem well defined enough to be computable by itself. |
It isn't, which is why computer scientists came up with things like BNF, SDL, VDM, Z, etc.
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Fri Feb 12, 2016 4:59 am Post subject: |
|
|
| 1clue wrote: | | The argument here IMO centers more around whether sql is a general purpose language. It's not. |
Ignoring the question of whether "the C family" should be considered to be a single language, there remain two problems of note with that line of reasoning in this context. First it was never specified that szatox meant anything other than what was literally in that post, specifically that "SQL is not a programming language", whether or not being Turing complete is a requirement for programming languages for something to be Turing complete does essentially imply that it is in some way a programming language. Second, the difference between a general purpose language and one that is not is essentially reducible to libraries and bindings, all it takes is one sufficiently bored individual to build an Qt interface for SQL and it would become, rather perversely, general purpose by most any common definition. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Feb 12, 2016 5:13 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | pilla wrote: | | English does not seem well defined enough to be computable by itself. |
It isn't, which is why computer scientists came up with things like BNF, SDL, VDM, Z, etc. |
Given a sufficiently capable computer, parser and lexical analyzer English would be turing complete. English is way overkill for that, and has many alternate meanings for a single word. That complicates things a lot.
What matters here is that "turing completeness" depends on whether it's possible, not whether it's easy.
Practically speaking, the only reason anyone would try this would be to create an AI, which IMO is a huge waste of time. |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Fri Feb 12, 2016 5:22 pm Post subject: |
|
|
| desultory wrote: | | 1clue wrote: | | The argument here IMO centers more around whether sql is a general purpose language. It's not. |
Ignoring the question of whether "the C family" should be considered to be a single language, there remain two problems of note with that line of reasoning in this context. First it was never specified that szatox meant anything other than what was literally in that post, specifically that "SQL is not a programming language", whether or not being Turing complete is a requirement for programming languages for something to be Turing complete does essentially imply that it is in some way a programming language. Second, the difference between a general purpose language and one that is not is essentially reducible to libraries and bindings, all it takes is one sufficiently bored individual to build an Qt interface for SQL and it would become, rather perversely, general purpose by most any common definition. |
While you're probably technically correct with reference to the difference between general purpose and a special purpose language, that sort of evades the point I was trying to make.
All computing languages are made with some sort of target in mind. C was designed for UNIX, to write the kernel and system services and apps. It's really good for that, and a lot of other things too. However it really sucks for other things, like communicating with a database.
SQL is designed to address the types of problems encountered when accessing a database. It's really good for that, and really bad at pretty much anything else. IMO that makes it a special-purpose language more than libraries and bindings. Nearly every language has some sort of library or binding to enable a sql-like interface to be injected into the source files directly, or referenced from some other file. Hibernate is one such tool, and ODBC/JDBC drivers often have a sql parser built-in, or rely on the database engine to do it. In this case you would pass sql straight to the driver rather than dealing with obscurities of ODBC directly. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Feb 17, 2016 10:25 am Post subject: |
|
|
Anyone who thinks C and C++ are the same language, needs to spend a good 6 months to a year in ##c
Or stop talking nonsense. ;-) |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Wed Feb 17, 2016 2:37 pm Post subject: |
|
|
| 1clue wrote: | | Fitzcarraldo wrote: | | pilla wrote: | | English does not seem well defined enough to be computable by itself. |
It isn't, which is why computer scientists came up with things like BNF, SDL, VDM, Z, etc. |
Given a sufficiently capable computer, parser and lexical analyzer English would be turing complete. English is way overkill for that, and has many alternate meanings for a single word. That complicates things a lot.
What matters here is that "turing completeness" depends on whether it's possible, not whether it's easy.
Practically speaking, the only reason anyone would try this would be to create an AI, which IMO is a huge waste of time. |
Actually, syntactic ambiguity is possible in English (and other human languages), which is one of the reasons why formal methods were devised. The most capable computer imaginable, the best parser imaginable, and the best lexical analyser imaginable could not resolve natural language ambiguities such as "John saw the man on the mountain with a telescope."
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Wed Feb 17, 2016 5:36 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | 1clue wrote: | | Fitzcarraldo wrote: | | pilla wrote: | | English does not seem well defined enough to be computable by itself. |
It isn't, which is why computer scientists came up with things like BNF, SDL, VDM, Z, etc. |
Given a sufficiently capable computer, parser and lexical analyzer English would be turing complete. English is way overkill for that, and has many alternate meanings for a single word. That complicates things a lot.
What matters here is that "turing completeness" depends on whether it's possible, not whether it's easy.
Practically speaking, the only reason anyone would try this would be to create an AI, which IMO is a huge waste of time. |
Actually, syntactic ambiguity is possible in English (and other human languages), which is one of the reasons why formal methods were devised. The most capable computer imaginable, the best parser imaginable, and the best lexical analyser imaginable could not resolve natural language ambiguities such as "John saw the man on the mountain with a telescope." |
And yet the human mind can process it easily.
Turing completeness does not care. The question is, can a Turing complete language be described in English without ambiguity? Could a computer be created which parses English or a subset of English and which is Turing complete?
There is no part of the definition which says a Turing complete language need ONLY have components necessary for Turing completeness.
Ambiguity can and frequently is misunderstood by humans, requiring clarification. |
|
| Back to top |
|
|
szatox
Advocate
Joined: 27 Aug 2013
Posts: 3150
|
| Posted: Wed Feb 17, 2016 5:53 pm Post subject: |
|
|
John is a bad example, to it's pretty funny one.
| Quote: | | "John saw the man on the mountain with a telescope." |
http://pl.tinypic.com/r/nq6amw/9
| Quote: | | John saw the man with a telescope on top of the mountain |
http://pl.tinypic.com/r/htwymc/9
| Quote: | | On top of the mountain, John saw the man with a telescope |
http://pl.tinypic.com/r/10n820n/9
Neither of the above really makes any sense, but they are not very ambiguous either.
However, you might want to bite on SNMP, AKA "Simple Network Management Protocol": I can't decide whether "simple" refers to the protocol, or the network part. Opinions expressed by the people who claim to have worked with it are not consistent  |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Wed Feb 17, 2016 5:59 pm Post subject: |
|
|
| szatox wrote: | John is a bad example, to it's pretty funny one.
| Quote: | | "John saw the man on the mountain with a telescope." |
http://pl.tinypic.com/r/nq6amw/9
| Quote: | | John saw the man with a telescope on top of the mountain |
http://pl.tinypic.com/r/htwymc/9
| Quote: | | On top of the mountain, John saw the man with a telescope |
http://pl.tinypic.com/r/10n820n/9
Neither of the above really makes any sense, but they are not very ambiguous either.
However, you might want to bite on SNMP, AKA "Simple Network Management Protocol": I can't decide whether "simple" refers to the protocol, or the network part. Opinions expressed by the people who claim to have worked with it are not consistent |
Or the management part.
Personally I think Simple describes the resulting self-image of the poor guy who's trying to learn it. |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Wed Feb 17, 2016 10:48 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | The most capable computer imaginable, the best parser imaginable, and the best lexical analyser imaginable could not resolve natural language ambiguities such as "John saw the man on the mountain with a telescope." |
Nor could a human; it's ambiguous to both. |
|
| Back to top |
|
|
Fitzcarraldo
Advocate
Joined: 30 Aug 2008
Posts: 2038
Location: United Kingdom
|
| Posted: Thu Feb 18, 2016 4:29 am Post subject: |
|
|
| steveL wrote: | | Fitzcarraldo wrote: | | The most capable computer imaginable, the best parser imaginable, and the best lexical analyser imaginable could not resolve natural language ambiguities such as "John saw the man on the mountain with a telescope." |
Nor could a human; it's ambiguous to both. |
Precisely. That's my point!
Hence the use of formal methods to attempt to eliminate the possible ambiguities of natural language (such as English) and force the designer to specify unambiguously the functionality required when designing software. Especially safety-critical software, which is why one finds well-known computer scientists such as David Parnas writing papers [1] with statements such as the following:
| David Parnas wrote: | 2 Documentation of Software Requirements
2.1 The Case for Formal Requirements
Modern computer systems must interact with a “real world” that can never be completely understood and completely described. If those that had to design, implement, and review the Darlington Shutdown Software had to know everything that could be known about the plant, the task would be of such complexity that nobody could tackle it. Luckily, only a small portion of that information is actually relevant to understanding the shutdown systems. This information can be summarised in a system requirements document that describes exactly what properties the shutdown system must have. The availability of this document should make it unnecessary for the system implementors to understand the highly complex environment in which it will be used. The document can be seen as a barrier that separates the complex details about the outside world from the complex details about the design of the computer system.
It cannot be expected that all the programmers working on a safety-critical software system will be intimately familiar with the requirements of the application. Even those who are specialists in the application may have differing ideas of the functions that a safety-system should perform. For this reason, it is essential that the plant engineers agree on, and precisely document, the requirements that the software must satisfy. If this is not done, or if the document is not complete and precise, the designers and programmers will be forced to deal with the complexity of the outside world and they will probably make errors as a result.
For similar reasons it is essential to any software quality assurance (QA) group that they be given a precise statement of the requirements that the software must meet. For example, the Queen's group, while it had some expertise on software, had little information about Nuclear plants. The software specialists at Queen's could not be expected to determine whether or not a program would perform correctly unless they were told exactly what that would mean.
Years of experience with documentation written in broad variety of natural languages have shown natural language to be inadequate for the task of precise requirements specification. There are always unsuspected ambiguities in natural language specifications. For example, consider the simple statement,
“Shut off the pumps if the water level remains above 100 meters for more than 4 seconds.”
Although this sentence appears clear, if we remember that the water level could be varying over the 4 second period, we can find at least three reasonable interpretations:
.
.
|
_________________
Clevo W230SS: amd64, VIDEO_CARDS="intel modesetting nvidia".
Compal NBLB2: ~amd64, xf86-video-ati. Dual boot Win 7 Pro 64-bit.
OpenRC systemd-utils[udev] elogind KDE on both.
My blog |
|
| Back to top |
|
|
1clue
Advocate
Joined: 05 Feb 2006
Posts: 2569
|
| Posted: Thu Feb 18, 2016 3:37 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | Precisely. That's my point! |
I guess I can't decide which side of this argument you're on. Are you saying that English IS a Turing-complete language or that it isn't?
IMO, there's a difference between correct English, incorrect but understandable English, and correct, unambiguous English.
As with any human, if the input is not parseable into something unambiguous, you could print an error message. Something like, "Huh?" would probably be adequate. |
|
| Back to top |
|
|
bootle
n00b
Joined: 02 Apr 2003
Posts: 21
Location: Hamburg, Germany
|
| Posted: Wed Mar 16, 2016 8:25 pm Post subject: |
|
|
szatox wrote:
| Quote: | | SQL is not a programming language |
SQL is definitely a programming language, but it has a different
approach than procedural languages like C or Python which solve
tasks step by step. This comes close to common human thinking.
SQL, on the other hand, is almost pure set theory. It finds the
result of a query by applying its statements to entire sets
(usually heaps) of data (rows, columns, tables etc.) in one
single stroke. This requires a whole lot more abstractive ability
since you need to "see" those data heaps and their relations
before your inner eye in the first place.
------ |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Mar 18, 2016 1:00 pm Post subject: |
|
|
| szatox wrote: | | SQL is not a programming language |
| bootle wrote: | SQL is definitely a programming language, but it has a different
approach than procedural languages like C or Python which solve
tasks step by step. This comes close to common human thinking.
SQL, on the other hand, is almost pure set theory. It finds the
result of a query by applying its statements to entire sets
(usually heaps) of data (rows, columns, tables etc.) in one
single stroke. |
That's all true, but it is still not a programming language for two reasons; firstly it is a declarative data-definition and -manipulation language, not a general-purpose programming language (be that imperative, functional or logical.)
Secondly, like C++, it took an ad-hoc approach to language design, with much the same outcome:
| Date, Darwen wrote: | SQL in particular is very far from ideal as a relational language:
This criticism has been elaborated by the present writers in many places; ...
To quote from the first of these books ["Relational Database: Selected Writings", 1986]:
"...it cannot be denied that SQL in its present form leaves rather a lot to be desired
-- even that, in some important respects, it fails to realize the full potential of the
relational model."
The basic problem (in this writer's opinion) is that, although there are
well-established principles for the design of formal languages, there is
little evidence that SQL was designed in accordance with such principles.
As a result, the language is filled with numerous restrictions, ad hoc constructs,
and annoying special rules.
These factors in turn make the language hard to define, describe, teach, learn,
remember, apply, and implement. |
from: "A Guide to the SQL Standard", C.J.Date with Hugh Darwen (3rd ed, corrected 1994); Ch 1.2
So as well as not being a general-purpose language, SQL also has no clarity; you cannot change this without designing a new language, in accordance with the basics.
In the C++ case, they are slowly iterating over that process every 5 years or so, to get to where LISP was 20 years before C++ started out, 30 years ago.
Though I don't think they will ever get rid of the ad-hoc parser, as backward-compatibility is much more important than people realise, especially when it comes to programming languages.
I agree SQL is code, though; just like make. ;) |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Mar 18, 2016 3:13 pm Post subject: |
|
|
| Fitzcarraldo wrote: | | The most capable computer imaginable, the best parser imaginable, and the best lexical analyser imaginable could not resolve natural language ambiguities such as "John saw the man on the mountain with a telescope." |
| steveL wrote: | | Nor could a human; it's ambiguous to both. |
| Fitzcarraldo wrote: | | Precisely. That's my point! |
I don't see how you're making a point about any language, by effectively discussing a syntax error, that a human would rightly reject, as we all have herein.
You can talk nonsense in a restricted subset, too. It might even sound vaguely plausible, as Markov generators show.
I guess your point is that at least it would be unambiguous nonsense, and could not have two meanings? ;)
Though it does show how language has been consistently dumbed-down in the last few millenia of "progress"; in Latin, say, there could not be any confusion. Showing it's not natural languages nor humans intrinsically that are the problem, but rather human propensities, such as gullibility on the one hand, and the sociopath (the original meaning of the word: "idiot") on the other.
It's much easier to flim-flam when ambiguity is inherent.
| Quote: | | Hence the use of formal methods to attempt to eliminate the possible ambiguities of natural language (such as English) and force the designer to specify unambiguously the functionality required when designing software. |
That has nothing to do with "formal methods", such as proofs, and everything to do with paying attention to the research from over 50 years ago, on what makes a language unambiguous.
It also has nothing to do with formal requirements, apart from that being a use-case for a "context-free"[1], or otherwise unambiguous, language.
Requirements must be phrased unambiguously, sure; but so must code, which came first in process terms: before the whole "requirements specification" hooha, we just used to call this area "planning" (or "design" if you were talking to most managers.)
It's much easier to use a black-box approach ime; humans are quite vociferous about feedback. (So treat them as a a black-box, instead of trying to make them into something they are not; apart from futility, that does not help your other users, the ones you never hear from.)
Note that we still require unambiguous languages, even if we gave up on the requirements-specification parade a while ago.
The trouble with it is, that it tends to ossify requirements that, it ultimately turns out, no-one really cared about.
But y'know, everything had to be haggled over, so by the time that crap was signed-off on, no-one wanted to expend the political capital to take it out, and more likely no-one even considered it. Since the process tends toward diffuse overview, rather than focus, everyone assumed someone else really needed it (or we'd never have spent all that time wrangling over it, right?)
Meantime the real requirements still haven't been winkled out, a social process more than a technical one, ime.
Unfortunately everyone's hung up on a resolutely anti-social process, in the misguided belief that many chefs help a broth, and technical must mean headache; so giving ourselves more headaches indicates we're technically competent, because we can push (others) on through a migraine.
But hey, we have all these bullet-points and now we can pretend that testing against those is going to deliver a working, if not satisfying, end-product, and here's lots more process we can add to that, to pretend that make-work is useful. ("Look: it's all formal, and proven, and stuff! And we had a committee-meeting and everything!")
Just one, rather jaded, take on it. ;-)
--
[1] in quotes, because there is no such thing in reality, but that's the term we have; it does apply at an implementation-level, but is imprecise imo.
LALR(1) is not much better, since it is not a general phrase. Really it's about not requiring an input-buffer, whether we use one or not.
So perhaps "buffer-free" would be better.
It most definitely is not state-free: the context is everything you saw up to that point.
"Linear" is another term that comes to mind, along with "sequential", or "serial". |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
