Recent

Author Topic: SOLVED: Where to post suggestions for changes to the language?  (Read 2661 times)

GypsyPrince

  • New Member
  • *
  • Posts: 31
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #15 on: October 27, 2020, 08:28:36 am »
 @440bx

Quote
if a Pascal compiler no longer considered the { and } as block comment delimiters, I seriously doubt everyone would be happy.  There is plenty of code out there that uses { and } to delimit comments.

Yeah, I figured it would probably wind up breaking some people's code and that it would be a no go.

Oh... and C will never die!!

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #16 on: October 27, 2020, 09:20:50 am »
C, as originally defined, is thoroughly dead: the community has had to adjust to the changes brought in by ANSI standardisation in the late 80s, and by progressive strengthening of typing etc. ever since. The practical result has been to move the semantics of C to something which is far more Pascal-like, but without its having been built on Pascal's fairly robust foundation and with a vast amount of legacy code that cannot be discarded.

It is unfortunate that so many people in the community are prepared to categorise languages into "C-like" and "Pascal-like" based sloely on the usage of braces. I can't help but feel that this indicates a lack of understanding that is hardly to their credit.

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8898
  • FPC developer.
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #17 on: October 27, 2020, 11:30:06 am »
It is unfortunate that so many people in the community are prepared to categorise languages into "C-like" and "Pascal-like" based sloely on the usage of braces. I can't help but feel that this indicates a lack of understanding that is hardly to their credit.

So true. Most of the language discussions are extremely superficial, often not even taking into account what can be done in the IDE to alleviate minor (perceived) problems.

MarkMLl

  • Hero Member
  • *****
  • Posts: 1449
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #18 on: October 27, 2020, 11:55:38 am »
So true. Most of the language discussions are extremely superficial, often not even taking into account what can be done in the IDE to alleviate minor (perceived) problems.

"THE CURLY BRACKETS ARE GREEN! THIS IS NOT A LANGUAGE I KNOW!"

Sorry, but even people who should know better regularly demonstrate that they don't know any better.

I still feel that we should strive for minimalism in a core language, hence my occasional comments on extensible syntax, unifying different structures and so on. But at the same time something that makes me very uneasy is when I come across a sequence like

* This is a list-oriented language, and every data structure is a list.

* Of course, we allow quoted strings as a convenience to programmers but they're compiled down to lists.

* But naturally, lists are optimised internally to blocks where this is possible.

I can't help but feel that there is something duplicitous about this. If in order to make a language useful and efficient there has to be "syntactic sugar" allowing e.g. quoted strings and machine-level handling of blocks of text etc., then neither the syntax, nor the semantics, nor the marketing should try to conceal this.

There are of course exceptions, e.g. I've read an interesting treatment which equated Prolog's reasoning ability to graph traversal, and there's a lot of clever memory management in there. But nobody in their right mind would claim that Prolog was a general-purpose language which could be used to e.g. write an operating system.

MarkMLl


Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

440bx

  • Hero Member
  • *****
  • Posts: 2048
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #19 on: October 27, 2020, 03:19:37 pm »
Oh... and C will never die!!
Unfortunately, you are probably right.  That said, pure C might die but extremely likely survive as a subset in C++.  The use of C or C++ will become "programmer's choice" of how to use the C++ compiler (which is already happening.)



Most of the language discussions are extremely superficial, often not even taking into account what can be done in the IDE to alleviate minor (perceived) problems.
I appreciate the help an IDE can provide but, I have mixed feelings about it.  Problems should be corrected at the language definition level not perpetuated by compensating for them in an IDE.

The "real" problem of course is that, once a language has been used to some extent then it becomes a prisoner of its own success which makes it very difficult and, in some cases impossible, to correct deficiencies without affecting existing code.



I still feel that we should strive for minimalism in a core language,
I completely agree.  The more "hidden" work the compiler does on behalf of the programmer, the greater the probability the compiler feature will be misused.  An example, among a very large number, is the hiding and automatic dereferencing of pointers (classes) in FPC/Delphi.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

GypsyPrince

  • New Member
  • *
  • Posts: 31
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #20 on: October 27, 2020, 06:09:38 pm »
@440bx
 
I've been using C since 1987, and it is still my favorite language. Unfortunately, there are very few pure 'C' compilers left as most C these days is compiled in a C++ compiler which is a bit like putting a Lexus emblem on a Toyota. It's made by the same company, and they look just alike, but there is a difference under the hood, so the "Lexus" still performs merely as a Toyota. LOL
 
Like any other language, C had to evolve with the times to retain its usefulness. But because I understand it so thoroughly, I still love my old C. However, it's just not practical for what I do anymore. So, Lazarus/FP is stepping into its place. I think I've selected a great replacement.

440bx

  • Hero Member
  • *****
  • Posts: 2048
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #21 on: October 27, 2020, 07:49:49 pm »

Like any other language, C had to evolve with the times to retain its usefulness.
That's when what "usefulness" actually means is critical.  I've never considered C to be a "useful" language (except maybe now that it is part of C++ that has cleaned up some of the atrocities in it and does a reasonable amount of type checking.)  There are only two reasons I've reluctantly used C, the first one is because a lot of algorithms were implemented in C and, the other is that it could be used as a high level assembler that was usually fairly decent at optimizing code.

But because I understand it so thoroughly, I still love my old C.
I'm the exact opposite.  The more I understood it and the more expertise I acquired in it, the more I disliked it.  The C language is a genuine insult to computer science.

So, Lazarus/FP is stepping into its place. I think I've selected a great replacement.
For RAD, Lazarus is quite nice.  Pascal, as implemented in Delphi and FPC, has the potential to be significantly superior than C/C++ but, unfortunately, it only accomplishes that in a few areas.

One thing we both know is that C is here to stay.  Very unfortunately, that may not be the case for Pascal in the long run.
FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

marcov

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 8898
  • FPC developer.
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #22 on: November 16, 2020, 10:56:30 pm »
Most of the language discussions are extremely superficial, often not even taking into account what can be done in the IDE to alleviate minor (perceived) problems.
I appreciate the help an IDE can provide but, I have mixed feelings about it.  Problems should be corrected at the language definition level not perpetuated by compensating for them in an IDE.

But what a "problem at the language definition level" really means is not an universal truth. The need of shorthand is not a language dialect problem, but a problem of typing aids i.o.w. the editor.

Quote
The "real" problem of course is that, once a language has been used to some extent then it becomes a prisoner of its own success which makes it very difficult and, in some cases impossible, to correct deficiencies without affecting existing code.

And more importantly, if you set a low bar for language extensions, the likeliness that you will become such a prisoner increases.

And you can never rule out compatibility. We had the "break away from TP/Delphi" arguments already back then when mode FPC introduced the "@" for procedure variables. It seemed like an good idea to disambiguate a certain construct.

But now we are over twenty years later, and we still are adding and removing @'s when moving dialects, for a corner case ambiguity of a function returning a functiontype.

I still feel that we should strive for minimalism in a core language,
I completely agree.  The more "hidden" work the compiler does on behalf of the programmer, the greater the probability the compiler feature will be misused.  An example, among a very large number, is the hiding and automatic dereferencing of pointers (classes) in FPC/Delphi.

IMHO aimless minimalism is as bad as baroqueness. Years of pointless manually crafting string code in Modula2 taught me that.

440bx

  • Hero Member
  • *****
  • Posts: 2048
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #23 on: November 17, 2020, 05:57:09 am »
I thought this thread was done... I guess not  :D  But, it still won't make any difference.

But what a "problem at the language definition level" really means is not an universal truth.
I doubt that.  The language structure as defined in its grammar is where problems are solved/avoided or created.  Deficiencies in a language point directly to deficiencies in its grammar.

The need of shorthand is not a language dialect problem, but a problem of typing aids i.o.w. the editor.
I don't consider having to type "begin" or "end" a problem.  shorthand is something an editor can handle but, no editor can eliminate deficiencies in the language's grammar.

And more importantly, if you set a low bar for language extensions, the likeliness that you will become such a prisoner increases.
In a well designed language, extensions should be few and far between.  That's one of the main indicators it is/was well designed.  "Extensions" should be in libraries not in the language.

And you can never rule out compatibility. We had the "break away from TP/Delphi" arguments already back then when mode FPC introduced the "@" for procedure variables. It seemed like an good idea to disambiguate a certain construct.
I don't rule out compatibility.  Compatibility is the ever present Damocles' sword hanging over a language definition.  Every "extension" to the language grammar itself is an event that can cause that sword to fall on the user.  Particularly when those extensions tend to be casual or capricious (binary sugar extensions.)

IMHO aimless minimalism is as bad as baroqueness. Years of pointless manually crafting string code in Modula2 taught me that.
Minimalism isn't the problem.  Incompleteness and Inconsistency are the problems.  Those lead to a steady stream of language "extensions" which often cause problems due to their causing inconsistencies in the language.  Both, FPC and Delphi are victims of that.



FPC v3.0.4 and Lazarus 1.8.2 on Windows 7 64bit.

egsuh

  • Hero Member
  • *****
  • Posts: 504
Re: SOLVED: Where to post suggestions for changes to the language?
« Reply #24 on: November 17, 2020, 05:59:37 am »
JUST REFRESHMENT!!

Regarding braces, recently I've learned javascript and it uses braces --- they are difficult to read as I'm taking ages one by one :D.  And I hate pressing shift key. Typing begin...end and declaring every variable and procedure/function in the interface part frequently annoys me. But later they are much better. Easy to read, and I only have to print interface parts when I try to use the units in other programs.

I'm not a proper programmer and do not do much programming,  so I do not know exactly what heavy programmers experience. Of course it is cumbersome to type long keyword/identifiers to me as well. But they are easier to read and understand afterwards, which is very important in maintenance.   

 

TinyPortal © 2005-2018