Recent

Author Topic: Re: language improvement suggestions (the spin off)  (Read 16995 times)

440bx

  • Hero Member
  • *****
  • Posts: 5010
Re: Re: language improvement suggestions (the spin off)
« Reply #30 on: November 25, 2019, 03:17:19 pm »
Well Pascal is not Kotlin or Cobol anyways  :D
this discussion will never end, points from one side or another never ends if you have enough imagination-
That points to the real problem computer language design faces. Currently, there is no universal, precise and accurate way of _measuring_ the logical usefulness of a specific language construct, much less that of a grammar as a whole. That causes a lot of problems, among them, "religious allegiance" to specific computer languages which often manifests itself in a strong resistance to improvements.

If culinary chefs designed their dishes the way computer languages are designed, you could not have ham, eggs and toast together for breakfast.  You could have ham or eggs or toast but, "contaminating" one with either one of the other two would be unacceptable.

You want EVALUATE, use COBOL.  You want flexible array members, use C. You want sets, use Pascal. You want inline scopes, so far, you're out of luck ... and so on. If Burger King sold compilers their motto would be "you can have it _our_ way."

It's no wonder even after 40+ years since the first compiler, computer languages have barely improved compared to the advances made in other areas.   


(FPC v3.0.4 and Lazarus 1.8.2) or (FPC v3.2.2 and Lazarus v3.2) on Windows 7 SP1 64bit.

MarkMLl

  • Hero Member
  • *****
  • Posts: 8234
Re: Re: language improvement suggestions (the spin off)
« Reply #31 on: November 25, 2019, 04:18:20 pm »
It's no wonder even after 40+ years since the first compiler, computer languages have barely improved compared to the advances made in other areas.

Make that 60 years after ALGOL-60, and a few years more since Knuth et al. started working out how to write compilers methodically.

The real tragedy is that "modern" language developers seem to be putting all their effort into reinventing the facilities provided by Delphi v1: dynamic strings, good cross-unit facilities, and above all a moderately-strong type system.
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

del

  • Sr. Member
  • ****
  • Posts: 258
Re: Re: language improvement suggestions (the spin off)
« Reply #32 on: November 25, 2019, 06:23:31 pm »
It's no wonder even after 40+ years since the first compiler, computer languages have barely improved compared to the advances made in other areas.

People still sometimes say that C++ is a superset of C. Sure - just like a Cube is a superset of a Line.

Thaddy

  • Hero Member
  • *****
  • Posts: 16580
  • Kallstadt seems a good place to evict Trump to.
Re: Re: language improvement suggestions (the spin off)
« Reply #33 on: November 25, 2019, 06:57:39 pm »
People still sometimes say that C++ is a superset of C. Sure - just like a Cube is a superset of a Line.
It is actually the occurrence of a structured pattern in randomness. It is a fluke, as proven from the fact it changes by whichever side you look at it,

Can also be explained by "Mechano": if there's not enough holes left, un-bolt one and add a new strip...
« Last Edit: November 25, 2019, 06:59:53 pm by Thaddy »
But I am sure they don't want the Trumps back...

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Re: language improvement suggestions (the spin off)
« Reply #34 on: November 25, 2019, 07:18:41 pm »
Oh no!

One of the first languages (the third after Fortran and Basic) I learned, was Forth:
I would like a{$modeswitch reversenotation}


Vade retro, Satana!

Winni

Thaddy

  • Hero Member
  • *****
  • Posts: 16580
  • Kallstadt seems a good place to evict Trump to.
Re: Re: language improvement suggestions (the spin off)
« Reply #35 on: November 25, 2019, 07:46:14 pm »
Vade retro, Satana!
Videte quid optae

Sums it up I guess..
« Last Edit: November 25, 2019, 07:48:37 pm by Thaddy »
But I am sure they don't want the Trumps back...

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #36 on: November 25, 2019, 08:29:33 pm »

Ok, so to conclude...

There are functional bits, such as:
* The read-only pre-eval.  They could be done by various other constructs (e.g. extended "with" / in itself a topic for fierce discussions) => but thats not the point.
* The  check of all columns (all conditions in each line) being present (albeit, present does not imply correct)

There are bits that already exists.
* Counting how many "when" lines there are. => Same as counting IF lines.

There is a danger (the extend of which we have a major disagreement on) of messing things up, since it relies on good vertical alignment (and the users ability to track this alignment).
Of course an editor can draw vertical help lines, but then the benefit comes from the editor and not the feature

We simple have different opinions on the "readability" bit.
I do agree that tables can present data in a very readable manner, but that is if the app that displays the data supports displaying the table, with guidelines or the like.
In a text editor "tab" like formatting (even with spaces) can improve readability. But IMHO it depends on the data already being somewhat readable before. "Tab" are not magically turning unreadable data to readable. Hence my demand for "as"


There are potential additions, such as adding "as" to evaluate. ("If" already has them). Apparently we can not agree on this. But it probably depends on how well your Editor helps tracking columns, and even more on what the actual use case of "evaluate" is.
- Assuming best case: Fits on one screen, and each column has different types.
- Assuming worst case: goes way off screen, and columns have compatible types.
Of course even the best feature has a "bad" worst case.
However I cannot help but wonder: One of the "advantages" you listed (the ability to count "when" and compare to the expect variation count of a boolean matrix) is actually falling into "worst case": all/most columns are boolean, and a long list of "also true also false also false also true ....", is really easy to mix up (swap columns). Maybe that is not the typical use case, but it is the example that you build part of your case on.
Anyway, apparently at least you had never issues with accidental mix ups...


As for your graph: The have diff levels of details. Also despite we type "else if" and not "elseif" for the human reader (and for this usecase) they are the same. If you read it as "elseif" then there is no nesting.
"nested if" are different to "waterfall if elseif...". And like "nested if", you can have "nested evaluate" (though that would be foolish)



One last note on readable and screen size.
"evaluate" fits into one particular "need". Since it has a shorter syntax, and omits "as alias" the overall representation fits on a smaller space. (And yes as long as this space is very small, it is still readable...).
So if one has a lot of data, and needs to "squeeze" it onto one screen, then "evaluate" can help.
Though the word "squeeze" already tells, that this is not a good thing. It simple opens a way to defer solving one problem by choosing a new "lesser" problem.

For the very same reason, I have seen people (and done myself) using none-descriptive short identifiers and weird code formatting.

The real answer (one of the answers) is to modularize your code (refactor, split out some logic, ....).

kupferstecher

  • Hero Member
  • *****
  • Posts: 603
Re: Re: language improvement suggestions (the spin off)
« Reply #37 on: November 25, 2019, 10:12:32 pm »
New feature? I need this:
A keyword "this" which refers to the left side of the statement.

Examples:

Code: Pascal  [Select][+][-]
  1. aVar:= this + 1;   //Equals to aVar:= aVar + 1;
  2. aVar:= this * (this -1);
  3. DrawGrid1.Font.Style:= this + [fsBold];   //Equals to DrawGrid1.Font.Style:= DrawGrid1.Font.Style + [fsBold];

The syntax is imho quite pascalish. The advantage is, that the right side of the statement is generic, this reduces mistakes and improves readability.
I've never come across such a feature in any language, but time by time I stumble upon a situation where it would be quite helpful.
 :)

del

  • Sr. Member
  • ****
  • Posts: 258
Re: Re: language improvement suggestions (the spin off)
« Reply #38 on: November 26, 2019, 01:10:47 am »
New feature? I need this:
A keyword "this" which refers to the left side of the statement.

Examples:

Code: Pascal  [Select][+][-]
  1. aVar:= this + 1;   //Equals to aVar:= aVar + 1;
  2. aVar:= this * (this -1);
  3. DrawGrid1.Font.Style:= this + [fsBold];   //Equals to DrawGrid1.Font.Style:= DrawGrid1.Font.Style + [fsBold];

The syntax is imho quite pascalish. The advantage is, that the right side of the statement is generic, this reduces mistakes and improves readability.
I've never come across such a feature in any language, but time by time I stumble upon a situation where it would be quite helpful.
 :)

I could get used to this. It shouldn't arouse the C Haters. And it's actually an improvement over

Code: Pascal  [Select][+][-]
  1. a += 10;

syntax in that it not only deals with booleans and boolean operators (which C / C++ does not), but also just about anything else. Readability - the key to robust code.

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Re: language improvement suggestions (the spin off)
« Reply #39 on: November 26, 2019, 01:41:03 am »
Hi!

Using the right syntax saves a lot of typing

* Example1: change it to
Code: Pascal  [Select][+][-]
  1. inc (aVar);
Some chars saved

* Example2:
Code: Pascal  [Select][+][-]
  1. aVar := aVar*(aVar - 1);
Zero chars saved

* Example3:
Code: Pascal  [Select][+][-]
  1. include (DrawGrid1.Font.Style, fsBold);
  2.  
4 Chars saved

Just because in some crazy languages the students have to learn "this" - it is not necessary.
I'm bothered about the C style operators.
And I was bothered about the about the basic style oprators "Trim" and the string concatenating with "+". Long time ago.

We dont need no "this" (or that) enhancement.

Winni



del

  • Sr. Member
  • ****
  • Posts: 258
Re: Re: language improvement suggestions (the spin off)
« Reply #40 on: November 26, 2019, 03:58:28 am »
Hi!

Using the right syntax saves a lot of typing

* Example1: change it to
Code: Pascal  [Select][+][-]
  1. inc (aVar);
Some chars saved

* Example2:
Code: Pascal  [Select][+][-]
  1. aVar := aVar*(aVar - 1);
Zero chars saved

* Example3:
Code: Pascal  [Select][+][-]
  1. include (DrawGrid1.Font.Style, fsBold);
  2.  
4 Chars saved

Just because in some crazy languages the students have to learn "this" - it is not necessary.
I'm bothered about the C style operators.
And I was bothered about the about the basic style oprators "Trim" and the string concatenating with "+". Long time ago.

We dont need no "this" (or that) enhancement.

Winni

I know you're being sardonic. But let's try this again. This time with a relevant example:

Code: Pascal  [Select][+][-]
  1. //bad:
  2.  
  3. super.duper.big.mile.long.variable.that.fills.up.half.the.editor := super.duper.big.mile.long.variable.that.fills.up.half.the.editor - 1;
  4.  
  5. //better:
  6.  
  7. super.duper.big.mile.long.variable.that.fills.up.half.the.editor := this - 1;
  8.  

Can you dig it? I knew you could.  8-)

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Re: language improvement suggestions (the spin off)
« Reply #41 on: November 26, 2019, 04:11:31 am »
Hi!

I am not sardonic. I only know that optimists have a deficit on informations.


And to your example:

wrong:
procedure Foo(Super: SomeType);

right:
procedure Foo (Editor: AnotherType);

Winni


Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: Re: language improvement suggestions (the spin off)
« Reply #42 on: November 26, 2019, 04:25:01 am »
Code: Pascal  [Select][+][-]
  1. super.duper.big.mile.long.variable.that.fills.up.half.the.editor := super.duper.big.mile.long.variable.that.fills.up.half.the.editor - 1;
  2.  

Code: Pascal  [Select][+][-]
  1. if Supercalifragilisticexpialidocious is hippopotomonstrosesquipedalian then
  2.   goto Llanfairpwllgwyngyllgogerychwyrndrobwllllantysiliogogogoch;
« Last Edit: November 26, 2019, 04:27:01 am by Martin_fr »

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Re: language improvement suggestions (the spin off)
« Reply #43 on: November 26, 2019, 04:32:34 am »
Yes - the first was an italian hit in the 60th (Rita Pavone?).

And the third was a pub in my hometown, but the name was stolen from Ireland(?).

But goto is disabled. Poor me.

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 10837
  • Debugger - SynEdit - and more
    • wiki
Re: language improvement suggestions (the spin off)
« Reply #44 on: November 26, 2019, 06:01:47 am »
I split the topic. So the OT of the original post can look at the answers related (and vaguely related) to his question.

 

TinyPortal © 2005-2018