Larkin, Power BASIC cannot be THAT good:

On a sunny day (Sat, 23 May 2009 09:22:09 +0100) it happened Nobody wrote in :

way,

OK, so to each his own perhaps. 'Language wars', 'editor wars' I have seen it all happening on Usenet. Before we start throwing the pies, maybe we can agree on some statement... like they do after those failed political meetings of our leaders... "That although not a single POV is the same, we have agreed that the weather will likely change frequently and there is still hope for future progress, and a new meeting will be arranged to discuss the issues further." That said, in a final statement, I declare what they call C++ and you refer to that C++ as OO, sucks.

Now, well, OK, now that I started to write anyways... what the big mistake is, is in my view that Strouskop (or whatever his name is), and maybe others too, seem to think 'big problems' are things that need to be solved by 'one big program'. If you think that, and would actually try that, then you get huge sources that need to somehow be compiled together, and the thing becomes more and more difficult, and likely impossible, for mere humans, to maintain.

This is _not_ how 'big problems' are solved.

As I mentioned before, the architect who does not know about stones and concrete, and dreams up a castle. will be in big trouble once building starts.

*If* it ever starts, because he may have requested the impossible. I do not know exactly where the limit for a 'big' or a 'small' project is for you, but somebody here mentioned 70k lines of code, maybe 100k, maybe less.

In reality something of what _could_ be conceived as a big project, as an example I have here: I want to say 'show ARD' (Ard is a German public broadcaster) and then I want that satellite station to appear on my desktop monitor in full screen, de-interlaced. Now in a way that involves: 1) voice recognition, 2) satellite dish positioning,

3) satellite reception, 4) mpeg2 decoding. 5) mp2 decoding, 5) display, 6) Ceefax (teletext) decoding and display, etc. etc. That would, if you wrote it from scratch, take lot more then say 500k lines of code. But we do not DO it that way, we are smart, and use PROGRAMS to do those essential parts, and Unix (Linux) allows you to chain things together nicely.

Also here departs *my* view from what you commonly see in Linux, 'video for Linux' (v4l)..... v4l tries to do all thing by itself, and is therefore always one step behind, as it never supports anything new, as that has not been integrated yet, also an ever changing API, now we are at v4l2, and of course not compatible. I decided to use pipes, and pipe the video stream from one application to the other... A much simpler way, and if you wrote some application, say a filter, or some processing, then you just pipe the stream through it.... So what that boils down to is that you do NOT have one big application, but a whole lot of universally applicable small ones, that are each easy to maintain, and can easily interface with other things in the world, other applications, and hell if you are so inclined you can call these small applications 'objects', buy of course they are not objects, they are different programs, possibly written in different languages, working together to get the job done. In the example I gave you speak into the microphone, that is monitored by 'perlbox voice' (written in you guessed it "perl"), perlbox voice calls the voice recognition suite 'Sphinx2' and the Festival speech synthesiser, both rather large university related projects, Once perlbox recognises the 'show ARD' command, it executes a bash script I wrote called 'show'. The bash script will execute a C program I wrote called 'xdipo' that positions the disk, and then tunes the sat card in the PC to the station ARD (frequency and parameters found in the script), by calling the sat card driver, this driver output the transport stream (.ts that holds all the audio, video, text, etc.. stuff) on /dev/dvb/adapter0/demux0 after tuning it via /dev/dvb/adapter0/frontend0 ... this is then piped to a C program called 'jpinfo' that I wrote that extracts the required streams, that is then piped to the 'xvtx' C program I wrote to display Ceefax (teletext) on screen text if required, that is then piped to xine, a media player written in C++ (I think).... or mplayer (written in C), and those then use the Xwindows system to display it on my screen, and the Alsa sound system to play the sound via the sound card, calling the needed decoders for video and sound. those are written in C and partly asm, and all that runs on top of Linux which is written in C. A million lines of code perhaps (if not more) to 'show ARD'. problems? What problems? Modularity? Right there. Object oriented, not if you use mplayer and not xine... So 'syntactic sugar' is a very polite way to refer to the object oriented paradigm, it comes from wanting to do too much at one time perhaps... maybe, and this is my view, from wanting to do all of the above in one program... Not possible, not in the least because you never have all that knowhow..... Nobody does >?> Nobody ;-)

Reply to
Jan Panteltje
Loading thread data ...

way,

program'.

need to

and likely impossible,

I agree with you (for a change). Several others and myself are working on a fairly complex system. We divided the software into several seperate simple programs which share a messaging system and a database.

processing, then you just pipe

This is exactly how Microsoft Directshow works. Its a chain of programs processing audio and/or video.

whole lot of universally applicable small

things in the world, other applications,

'objects', buy of course they are not objects,

together to get the job done.

You just captured the whole meaning of object oriented design.

--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
                     "If it doesn\'t fit, use a bigger hammer!"
--------------------------------------------------------------
Reply to
Nico Coesel

program'.

need to

It doesn't need to be a large monolithic executable. If anything, OO is particularly suitable for libraries, as virtual methods make it easy to extend the library without needing to modify the source code.

But splitting a program into libraries (or multiple programs) doesn't, by itself, reduce the maintenance burden or the the overall complexity. If all of the libraries fit within a common framework, the system isn't really much different to a monolithic program. If they don't, the system is likely to be even more complex as a result.

There are cases where that imposes an unacceptable performance penalty, as you can't just pass references (pointers) through a pipe; you have to pass the data as well.

And you either have to export/import the data to/from a defined protocol, or your internal format becomes the defined protocol, which means that you haven't necessarily modularised anything.

It can also become a maintenance nightmare, as you need to extend the protocol in order to add additional data. All modules which process the data have to understand the new protocol, even those which don't use the additional data.

OO gets around this by "publishing" the specification while hiding (most of) the implementation details.

E.g. you might have a "dictionary" (associative array) class, with methods to add, remove and look-up entries. The implementation could be a B-tree or a hash table or even just an array; code which uses it doesn't need to know the details, and doesn't need to change if the implementation changes.

You can even have multiple implementations to allow for different implementations being more efficient for specific use cases, or having additional features, and any code which accepts a dictionary as an argument will work with all implementations, including those which were added later.

Reply to
Nobody

Except, it's not programs but DLLs which all execute within the application's address space.

And the design is heavily OO, with the graph nodes implemented as subclasses of CBaseFilter.

Er, not really. That's more a description of modularity in general.

OO provides a specific form of modularity through abstraction, i.e. public interface, hidden implementation. Objects are defined by their semantics (what you can do to them) rather than their syntax (what they are made of).

The Unix "pipeline" philosophy is contrary to OO, in that it separates the code from the data, so the format of the data must be globally known. OTOH, OO ties the code and data together so that the data is only accessed through its associated code.

OO is more about *enforcing* modularity than merely providing it. This allows you to change the "internals" of a component without having to analyse vast amounts of code to see if anything is relying upon the details of the existing implementation.

[Unix analogy: the NSS (name-service switch) mechanism allows user and host information to be obtained from plain text files (/etc/passwd, /etc/hosts, etc (no pun intended)), Berkeley DB files, NIS, LDAP, DNS etc. The client just calls e.g. getpwent() rather than parsing /etc/passwd and failing on a system which uses NIS.]

Java takes this a step further an uses the encapsulation as a security mechanism. You can pass an object reference to arbitrary code, safe in the knowledge that the recipient can only access the object through the provided interfaces.

[Unix analogy: a restricted file which normal (non-root) users can only access via a setuid/setgid binary. E.g. you can't modify /etc/passwd directly, but you can use chsh and chfn to change *your own* shell and full name.]
Reply to
Nobody

On a sunny day (Sat, 23 May 2009 19:14:58 +0100) it happened Nobody wrote in :

that need to

Actually it does make a difference, you use common 'bricks', like an architect uses the concept of those to build his idea into reality. The manufacturer of the bricks will change and improve his production process, maybe even change the materials used, but the brick spec will stay the same.

One would think this does, especially for video or multimedia. In practice this does not seem to be the case. Remember even in the drivers, in Linux for example 'copy to user' is used.. for the full data stream. memcpy() is very fast, with little overhead in modern processors. As a real test, no processor temperature increase one can measure from using the above concept. I monitor CPU temp always, as a way to see if the processor has a lot to do... top, xosview, all those tools, check for memory leaks, vmstat. As I am writing this this system is recording C5 from satellite in the UK, while doing time shifted playback with xine (we are in a commercial now), while encoding in a similar way (mcamip) h264 to file, running a web server, and a ftp server with sometimes heavy transient load. And the dns server too. Oh, but it is also playing mp3 in the background, 2 web browsers open, this newsreader, and it controls the home climate system... at the same time, processor load is still very low.. load average is always converging to about 1. Tasks: 126 total, 2 running, 123 sleeping, 0 stopped, 1 zombie Cpu(s): 2.0% us, 6.3% sy, 44.9% ni, 31.4% id, 10.6% wa, 1.7% hi, 3.3% si Hey the recoding pipes do not even show up :-) Pipes are cool. The 2 shown running are the security cam and H264 encoder.... those take some cycles.

You have to agree on a format, like you have to agree on a language when you want to talk to somebody, like agreeing on using English here. Same for applications. You do not normally half way a conversation change language.

'as'? There is no need to 'change protocol', you have only the data stream, and you can do with that what you want, or split it with 'tee' and feed it to other applications that may change the data stream into other formats, like codecs, there is the top script that decides how the chains are put together, a _true_ top-down approach from that POV, but it could never be created without you knowing what the blocks you use to build the towers can do and stand.

To expect a block, or brick to 'be able to everything' because of some mysterious mechanism added to it, is lunacy building, and it will always fail, as bricks should stay bricks and do exactly what they are supposed to do.

Well the best of luck with it, no wonder that stuff gets so hopelessly bloated and as I mentioned before, is a dead end street, one with no return, into bloat and disaster. That is what C++ is, and MS is a living, or rather dying (see Vista) example of that.

Beep, input error.

Reply to
Jan Panteltje

There is a fundamental difference between goto and gosub. It is an important one, subroutine invocation saves time and code space without the biggest problems of goto.

Reply to
JosephKK

But GOTO is faster than GOSUB.

You can make a very nice state machine with an ON..GOTO (or equivalent CASE...GOTO) structure that dispatches to a number of snippets, each of which does its thing ends with a GOTO back to the top of the state dispatcher. Works like a trained pig.

John

Reply to
John Larkin

Unless you're running a processor running in the single digit megahertz, programmer development time, code reliability and maintainability are far more important than raw speed. It hardly matters if a subroutine finishes in 0.0015ms instead of 0.0012 ms when the process being monitored takes 5ms.

BASIC is a shitty language because no two implementations are compatible. Everything with named variables, constructs, code blocks, parameter passing, if/then/else, case statements, etc. required proprietary extensions.

Reply to
AZ Nomad

:

programming.

and

simplest way,

can

feasible,

and

mistake is,

others too,

big program'.

sources that need to

difficult, and likely impossible,

some processing, then you just pipe

but a whole lot of universally applicable small

other things in the world, other applications,

'objects', buy of course they are not objects,

working together to get the job done.

Could very well be. And object oriented should stop dead right there. Trying to make a programming language object oriented is a fools errand. Object is a worthy abstraction. Carrying it too far is an error, thus c++ is an error. Part of the issue is trying to conflate static languages and dynamic languages, another error.

Reply to
JosephKK

passing,

parallelised

that's

1 language identified and verified. Don't think i ever heard of it before.
Reply to
JosephKK

Thus my limitation. I did not want to hear about C (fork()) and threads let alone heavyweight versus lightweight processes.

Reply to
JosephKK

Do I have to give all the money back?

John

Reply to
John Larkin

Nah. Just learn a completely new proprietary langauge every time you try BASIC with a different vendor.

Reply to
AZ Nomad

Neither fork() nor pthreads are part of the standard C library as defined by the ANSI/ISO standards.

If you exclude language features implemented through the standard library, some languages don't even provide assignment. E.g. in Lisp, assignment is via set/setq/setf functions, not an assignment operator, function definition is via defun, and so on.

Reply to
Nobody

I use PowerBasic for Windows apps. Why would I change vendors?

If you program C++/.NET, or C#, your programs won't be very portable. If you're careful and a little lucky, you can write Java programs that almost work the same under Windows and Linux.

I'm not a programmer, but I do need to program engineering problems. PowerBasic (the console compiler, not the real Windows thing) is fast and works well. These programs don't need to be portable... all I need them to do is to keep running under future revs of Windows. All my old

16-bit PowerBasic/DOS programs seem to work fine under XP, even the graphics. Only serial i/o is flakey, so we migrate them to PBCC, tghe 32-bit version, which does serial and TCP/IP just fine.

"Real" windows programming wastes too much effort on the user interface.

John

Reply to
John Larkin

Nokia bought trolltech, not Sun.

--Kim

Reply to
Kim Enkovaara

Thanks, you are right:

formatting link

I mixed this up with the Oracle/Sun thing:

formatting link

If there are more of such acquires, in the end there will be only a small number of very big companies.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Reply to
Frank Buss

analysis

basic

Unlike Dykstra, i do understand how to use goto to create case frames. And i use goto in ASM to build state machines as well. Goto is normally unnecessary in complete higher level languages like "C", and should be avoided in such languages.

Also gosub normally returns, even in ASM. =20

Reply to
JosephKK

=20

finishes

5ms.

compatible.

passing,

You seem to be confusing typical uP interpreter mid-1980's (tinybasic ala Gates) implementations with the actual original language as defined by its originators.

formatting link

formatting link

Reply to
JosephKK

defined

library,

is

Perhaps you will explain to us why Lisp does not provide assignment? What language properties / features causes this to be the case? (Never tried to use Lisp myself.)

Reply to
JosephKK

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.