LB Booster
General >> General Board >> Programming language's "simplicity"
http://lbb.conforums.com/index.cgi?board=general&action=display&num=1498552457
Programming language's "simplicity"
Post by flotulopex on Jun 27th, 2017, 08:34am

Richard,

...I just need to express a small frustration... grin

I'm an occasional programmer (as you may see in my threads...). Nevertheless, to make my programs do things I would like, even simple or basic things, I often need to know quite a lot about the programming language I have chosen (LB and recently BBC too) or the programs I make look (to me) far too "amateur" undecided (=> small things ALWAYS make THE difference!).

I just had a typical example where I had to set colors (...) and I couldn't find the way to; this made me search for hours and finally it ended up with a thread where, again, you helped me out wink

Almost anything is possible in LB or BBC BUT, making less than five little programs per year, I cannot remember subtleties that will make the result be nice and "completely made by my own". Should I better give up? Naaaaaa, that's not me!

I was wondering why actually this kind of things (like here, setting a color for a control) don't make me feel the language to be "intuitive" or "natural" when it comes to the programing.

For very simple things, BASIC is...simple. But why does is get so "complicated" (IMHO) when one wants to add some "look" or more "advanced features" to a program. Why does this language not have a kind of "logic"?

Maybe I'm of those that are confused about the language's name: BASIC.

My dream? A language named "Program as you speak". Possible?

Dreaming oh oh oh dreaming.... smiley
Re: Programming language's "simplicity"
Post by Richard Russell on Jun 27th, 2017, 2:55pm

on Jun 27th, 2017, 08:34am, flotulopex wrote:
But why does is get so "complicated" (IMHO) when one wants to add some "look" or more "advanced features" to a program. Why does this language not have a kind of "logic"?

Traditional BASIC (that is, the language as originally designed at Dartmouth College in 1964) hopefully is 'simple' and 'logical' in the sense in which you are using the words. However it is too simple for many modern programming tasks because (for example) it provides no mechanism for programming the GUI features that are so important in many modern applications. This is hardly surprising since the whole WIMP/GUI concept hadn't been thought of back then!

So that raises the question of how to 'extend' the BASIC language to encompass these modern requirements, and indeed whether it is appropriate to do so at all. It is here that different BASICs have diverged in a drastic way. The two dialects you mention - BBC BASIC and Liberty BASIC - could hardly be further apart in the ways they have tackled this issue.

BBC BASIC has not been extended to support modern GUI features, the dialect is substantially unchanged since the original 1981 version (there have been extensions in respect of available data types and how you can manipulate them, but not fundamentally in respect of input/output). This means that it is entirely dependent on external libraries (which may be BASIC libraries or DLLs etc.) in order to support these features at all. It is noteworthy, however, that this support has only been possible because BBC BASIC has some low-level features (such as direct access to memory and the ability to run machine code) that others don't.

So I would argue that BBC BASIC remains 'simple' and in the true spirit of a beginners' language. Of course you may well feel that the way the libraries support those modern GUI features is non-optimum, but that is separate from the language itself and somebody else could choose to do it differently without altering BBC BASIC.

Liberty BASIC, on the other hand, has gone down the opposite path of bolting on all sorts of extensions to the language itself, extensions which bear little resemblance to the characteristics and 'spirit' of the original BASIC language. I would suggest that it is these extensions that you find "complicated" rather than the parts of the language which are recognisably still 'BASIC'.

You would have to ask Carl Gundel why he chose that particular path, and whether with hindsight he might have done it differently. In creating LBB to be substantially compatible with LB 4 I have had no choice but to follow suit. So I can safely sit on the fence and let others argue over these issues!

Richard.
Re: Programming language's "simplicity"
Post by tsh73 on Jun 27th, 2017, 6:56pm

(just my 0.02$)
Quote:
Nevertheless, to make my programs do things I would like, even simple or basic things, I often need to know quite a lot about the programming language I have chosen (LB and recently BBC too) or the programs I make look (to me) far too "amateur" (=> small things ALWAYS make THE difference!).

Drive to perfection never ends. The trick is to stop just in time.

Quote:
Almost anything is possible in LB or BBC BUT, making less than five little programs per year, I cannot remember subtleties that will make the result be nice and "completely made by my own". Should I better give up? Naaaaaa, that's not me!

*me* set the plank substantially lower. If language gives me easy to use tool - fine. If no - I would not spend time diving into maze of API to achieve "anything". At least that was the plan wink

Quote:
For very simple things, BASIC is...simple. But why does is get so "complicated" (IMHO) when one wants to add some "look" or more "advanced features" to a program. Why does this language not have a kind of "logic"?


0) it (naturally) starts to get complicated then you want complicated things.
Just - it gets complicated a bit too early.
so I have some idea about why.
1) BASIC of simple things was devised in single piece, devised to be simple.
2) and it really got evolved over time, getting nicer
3) now things got hairy then BASIC got extended to things it never was supposed to
4) and I really feel that some of that extension was without any plan, ad-hock kludges. May be even different persons did things different ways. So things got inconsistent.
5) now, "right" way might be to put that pile back to the drawing board, redesign things so they get (more) consistent, and call it version+1.
- BUT - who have time to re-do things right (especially working ones)?
Besides, switching to new version will break compatibility with old programs
So we are here.

(BTW I have VB.Net with students this semester - having to declare every single variable really bothers me.
*and I really typed some stuff in JB to show things quickly.*
Who might think of it?)
Re: Programming language's "simplicity"
Post by Rod on Jun 27th, 2017, 8:00pm

You have to question why the language does not support the simple colouring that you desire. Answer, nobody used to use colour, colour was the choice of the user, the user decided on the colour scheme and all controls were supposed to be displayed in the colour contrast and font size of the users preference.


You see many multi coloured web and browser pages because that language was designed to support it. Step behind an office or retail screen and you will see few colours.
Re: Programming language's "simplicity"
Post by Richard Russell on Jun 27th, 2017, 8:30pm

on Jun 27th, 2017, 8:00pm, Rod wrote:
You have to question why the language does not support the simple colouring that you desire.

There's a particular oddity that led me to make LBB work differently from LB. In LB 4, the TextboxColor$, TexteditorColor$, ListboxColor$ and ComboboxColor$ variables are position-dependent, that is you can make different textboxes (etc.) have different background colors simply by setting the related variable before the statement that creates the control. This is explicitly illustrated in the LB docs with the following example:

Code:
  WindowWidth = 550
  WindowHeight = 410
  TextboxColor$ = "red"
  textbox #main.textbox1, 26, 16, 100, 25
  TextboxColor$ = "blue"
  textbox #main.textbox2, 30, 61, 100, 25
  TextboxColor$ = "yellow"
  textbox #main.textbox3, 30, 121, 100, 25
  open "untitled" for dialog as #main
  wait

Yet, in LB 4, the BackgroundColor$ variable, which sets the background color of the other controls, isn't position-dependent: you can't make different (e.g.) statictext controls have different background colors.

This seemed illogical to me, and in addition - given that LBB implements all the various controls using basically identical code - it would actually have been difficult not to make BackgroundColor$ position-dependent in the same way as the other variables, so it is!

Richard.