Recent

Author Topic: The future of Free Pascal  (Read 228504 times)

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #165 on: May 16, 2016, 01:13:03 am »

Object Pascal users were mostly on Windows, they just couldn't argument persuasively because they were detached from the open source world where ANSI C dominated due to existence of free compilers in the beginning of 90-s.
Now is a completely different context.
...
The only new language that solves many practical problems is Rust. But it's nailed to LLVM tools and completely depends on them, also Rust compiler is slow, and always will be, I guess. Rust is more difficult to read.
It sounds like you haven't actually actually used many other languages for production, yet you still try to make large scale generalizations and predictions. You probably can do much better if you actually get to learn stuff that you easily dismiss, so please stop this non-sense.

I don't use Lazarus because I prefer Emacs.
Using C++ in production means compiling for hours using ad hoc build tools.
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?

In the thread about future of Free Pascal you are posting about adding support to C++ in Lazarus(whatever that means) and advising to learn stuff.

ArtLogi

  • Full Member
  • ***
  • Posts: 184
Re: The future of Free Pascal
« Reply #166 on: May 16, 2016, 07:09:01 am »
Some talk have been made about embedded, I'm sure for most active readers/writers this project isn't nothing new, but for us newbies.  :)

https://ultibo.org/faq/
Quote
What programming language does Ultibo use?
Ultibo is written entirely in Free Pascal and is designed to act as a unikernel or a kernel in a run time library. That means when you compile your application the necessary parts of Ultibo are automatically included by the compiler so that your program runs without needing an operating system.
While Record is a drawer and method is a clerk, when both are combined to same space it forms an concept of office, which is alias for a great suffering.

ykot

  • Full Member
  • ***
  • Posts: 141
Re: The future of Free Pascal
« Reply #167 on: May 16, 2016, 04:59:03 pm »
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?
1. Yes. 2. What do you mean by "fail"? Compiler bugs and internal errors? I got my dose of them, so yes and no. :) 3. n/a.

In the thread about future of Free Pascal you are posting about adding support to C++ in Lazarus(whatever that means) and advising to learn stuff.
That is correct. :)

One of the biggest problems I have with C++ is the plethora of GUI libs without one being really dominant (QT and MFC comes closest). And QT is pretty but has MOCing issues, and no native windows offering and I never really liked MFC, it felt too much a macro set on top of winapi rather than an integrated offering.
Yes and this is why I like LCL approach more, where it really uses native controls on multiple platforms and its usage is pretty clean and intuitive.

Some talk have been made about embedded, I'm sure for most active readers/writers this project isn't nothing new, but for us newbies.  :)
Ultibo is quite nice, curiously I just checked it out few days ago and had no idea it used FPC. Raspberry PI is great, but by embedded platforms, I primarily meant embedded ARM and AVR. One of the things I would really love to see on somewhere around this web site, is a precompiled FPC/Lazarus bundle that can arbitrarily target Arduinos, much in the same way as Arduino IDE does. FPC already supports great deal of AVR chips and combined with Lazarus as IDE, it would be a much stronger alternative to Arduino IDE. Even so, maybe someone from FPC dev team can contact Arduino, asking for their financial backup to support a superior development platform? (I know they are probably trying to develop something of their own, but still...)
« Last Edit: May 16, 2016, 06:31:28 pm by ykot »

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #168 on: May 16, 2016, 10:32:19 pm »
Did you use Free Pascal in production?(I didn't) Did it fail? If so, why?
1. Yes. 2. What do you mean by "fail"? Compiler bugs and internal errors? I got my dose of them, so yes and no. :) 3. n/a.

It's a consumeristic approach to a non commercial tool.
You propose as an alternative a problematic language(C++) because its compilers benefited from many years and millions of corporative support(despite everything).
Taking that into account, it still lacks something similar with LCL's architecture, which you are pointing out as interesting.

Once, compiler writer Walter Bright finally gave up on C++ and developed a new language.

Ultibo posted earlier is an entrepreneur's approach, which is good and expected since authors are aussies(not ex-users of pirated Delphi on pirated Windows in ex-USSR):

www.youtube.com/watch?v=XfR9iY5y94s
« Last Edit: May 16, 2016, 10:53:14 pm by AlexK »

ArtLogi

  • Full Member
  • ***
  • Posts: 184
Re: The future of Free Pascal
« Reply #169 on: May 16, 2016, 10:46:43 pm »
It seems still to be distributed under some opensoftaware licence (I put it this way since I'm not too knowledgeable on these in general), even if does have enterpreteur aproach. Obviously if something like this is succesfull even as a standalone fork from the FPC it still benefits the whole object pascal community.  :)
While Record is a drawer and method is a clerk, when both are combined to same space it forms an concept of office, which is alias for a great suffering.

HeavyUser

  • Sr. Member
  • ****
  • Posts: 397
Re: The future of Free Pascal
« Reply #170 on: May 19, 2016, 03:25:42 am »
Actually pascal is the opposite of C/C++ the thinking is all backwards ee. variable declarations, for delcarations etc they are all backwards.

Repeat..until
For..in..do
For..to/downto..do
While..do

Variable declarations and types declarations are done right.

A good explanation what's a difficulty with C declarations - Go lang declaration syntax: https://blog.golang.org/gos-declaration-syntax

Quote
Go's declarations read left to right. It's been pointed out that C's read in a spiral! See The "Clockwise/Spiral Rule" by David Anderson.
Though I like C, can't say the same about C++.
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: The future of Free Pascal
« Reply #171 on: May 19, 2016, 08:37:23 am »
or in the worst case a DIY document how to patch or convert one for that hardware.
So do we, in a more general way as the options still need to be tailored for the specific hardware. "The rich gets richer, the poor gets poorer" applies in commercial programming industry. Vendors are likely to pick up major languages that can fit their hardware. Fighting back from inside requires huge effort to turn the market, which sounds impossible when done sporadically without commercial backup. You must learn how Sun can convince the world to switch over to Java in a C++ domination, despite it's a weaker product by a lot of ways.

HeavyUser

  • Sr. Member
  • ****
  • Posts: 397
Re: The future of Free Pascal
« Reply #172 on: May 19, 2016, 11:06:55 am »
So do we, in a more general way as the options still need to be tailored for the specific hardware.
No you don't, you have a generic how to code for embedded systems. I'm talking about specifics. You missed the point completely.
"The rich gets richer, the poor gets poorer" applies in commercial programming industry.
That's BS. It is not the commercial environment that has that effect and open source does not help to stop poverty. Lets not confuse the issue with useless politics.
Vendors are likely to pick up major languages that can fit their hardware.
Vendors will pick up whatever benefits them the most, language is not a direct variable on the that equation, but that should be self evident.
Fighting back from inside requires huge effort to turn the market, which sounds impossible when done sporadically without commercial backup.
erm fighting what or whom exactly?
You must learn how Sun can convince the world to switch over to Java in a C++ domination, despite it's a weaker product by a lot of ways.
OK, I'll byte, share with us your inside insight. How did sun managed to propagate Java?
« Last Edit: May 19, 2016, 11:18:58 am by HeavyUser »

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #173 on: May 19, 2016, 04:09:32 pm »
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.

C and C++ are different languages.
C99 standard has some features not available in C++: https://en.wikipedia.org/wiki/Flexible_array_member.

C99 array initialization(for C++ it was implemented only in g++ -std=c++11):
Code: C  [Select][+][-]
  1. int widths[] = { [10 ... 99] = 2, [0 ... 9] = 1, [100] = 3 };

Initializing array of struct:
Code: C  [Select][+][-]
  1. struct { int x,y; } ar[ 4] = { [1].x=23, [3].y=34, [1].y=-1, [1].x=12};

On the other hand, it took decades for C to start promoting types with defined size: int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.
Also:
int_leastN_t - signed integers with a width of at least N
int_fastestN_t - fastest signed integers with a width of at least N

There's no Boolean type in C.
Some type hints in C prevent or advice compiler's internal optimizations: volatile, restrict("restricted pointers", a hint).

Free Pascal has "absolute" keyword, practically undocumented, although the de facto convention is that compiler does not perform optimizations that would lead to necessity of compiler hints.
This area is still grey for me.

HeavyUser

  • Sr. Member
  • ****
  • Posts: 397
Re: The future of Free Pascal
« Reply #174 on: May 19, 2016, 05:05:16 pm »
;) agreed. C/C++ have got things backwards. But! They are everywhere, I can run a search for a compiler of any exotic embedded hardware and I bet that there is at least one C compiler or in the worst case a DIY document how to patch or convert one for that hardware. I would prefer to use pascal my self too but for now it has a position only my hobby projects.

C and C++ are different languages.
Well I have heard that many times over the years. Considering that C++ started as an extension that compiled code to C and not directly to cpu code it has more than 50% of language idioms shared with C that in my book makes them the same language, then again I consider turbo pascal 6~7 dialect the same language as delphi and object pascal, so interpretation is subjective and plays no major role on the syntax of those languages that was the topic on my comments not so much the features of each language. EE I do not think that FPC supports direct initialization of non local variable at all and I'm not sure it supports array initialization outside the const declaration. When I say got things backwards I mean declaration wise ee int X,Y; instead of X,Y : int; etc
C99 standard has some features not available in C++: https://en.wikipedia.org/wiki/Flexible_array_member.

C99 array initialization(for C++ it was implemented only in g++ -std=c++11):
Code: C  [Select][+][-]
  1. int widths[] = { [10 ... 99] = 2, [0 ... 9] = 1, [100] = 3 };

Initializing array of struct:
Code: C  [Select][+][-]
  1. struct { int x,y; } ar[ 4] = { [1].x=23, [3].y=34, [1].y=-1, [1].x=12};

On the other hand, it took decades for C to start promoting types with defined size: int8_t, int16_t, int32_t, int64_t, uint8_t, uint16_t, uint32_t, uint64_t.
Also:
int_leastN_t - signed integers with a width of at least N
int_fastestN_t - fastest signed integers with a width of at least N
first time encountering these constructs but if my interpretation is accurate then I need to read up on them. Thank you.

There's no Boolean type in C.
Some type hints in C prevent or advice compiler's internal optimizations: volatile, restrict("restricted pointers", a hint).

Free Pascal has "absolute" keyword, practically undocumented, although the de facto convention is that compiler does not perform optimizations that would lead to necessity of compiler hints.
This area is still grey for me.
All those features are good and all but it is not the features that will help the future of a language. I think that  uniqueness, comfort and speed of development is. I'm all for the "complete form" (sorry I'm stuck can't remember the proper word for it) of code that pascal supports but it needs to add features to reduce code from somewhere else to give an impression of smaller and easier to understand code base. Let them find their unique position on the market. RAD is a good arrow on their quiver along with the homogeneous component library but they suffer a bit on granularity. By the way no C/C++ is not the  future of FPC nor Java, .NET, python or any other language. They need to focus on one section and make sure that it does it better than every other tool on the market in a way that 1) everyone using it can be productive in a small period of time 2) colleges can use it to demonstrate/teach all the aspects of that sector in a concise and easily understandable manner. In short become THE right tool for a job. That's my opinion, so take with a grain of salt.

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #175 on: May 19, 2016, 10:42:53 pm »
All those features are good and all but it is not the features that will help the future of a language. I think that  uniqueness, comfort and speed of development is.

It creates an impression that languages move into the future. That's a side effect of the hype created by corporative languages.
As an analogy, some say that there's nothing new in automobiles since 1920s-30s, just optimization of the production process(also now cars are made so that it would be difficult or impossible to repair them in non-authorized shops).

C# tried to take Java's place, didn't make it. Then they tried to make it the language for the game industry. Game industry continued with C++ in its main part. When asked about GC, their answer is - "we use memory pools, each type has its own characteristics in time and space, so using a generalized GC is not efficient, and specific libraries from the start were meant to be written in C++, and for the scripting we use interpreters with REPL".

C# has coroutines, but such features usually make compiler more difficult to port, and coroutine is a special case of a class with a dispatcher method(no stack manipulation magic is required, though things get to look verbose).

They need to focus on one section and make sure that it does it better than every other tool on the market in a way that 1) everyone using it can be productive in a small period of time 2) colleges can use it to demonstrate/teach all the aspects of that sector in a concise and easily understandable manner. In short become THE right tool for a job. That's my opinion, so take with a grain of salt.

The focus is on portability of compiler, as I understand. Everything else depends on libraries.
Low level language can be perceived as high level due to specific libraries(C). Or high level language like Python, by using native modules, can do things that low level languages usually do.

AlexK

  • Jr. Member
  • **
  • Posts: 55
Re: The future of Free Pascal
« Reply #176 on: May 29, 2016, 09:22:09 pm »
One mistake(IMO) I noticed in the implementation, is making "program" statement optional. It was required in TurboPascal as I understand.

I use Emacs, and see benefits in that program statement, if it were required.
Given a large code base and required program statement, I could have just recursively grep(rgrep) a directory to find all "compilation entry points" of the code. In C it's a main function.

Would be usable in any other IDE.

Leledumbo

  • Hero Member
  • *****
  • Posts: 8746
  • Programming + Glam Metal + Tae Kwon Do = Me
Re: The future of Free Pascal
« Reply #177 on: May 29, 2016, 09:30:57 pm »
One mistake(IMO) I noticed in the implementation, is making "program" statement optional. It was required in TurboPascal as I understand.
Nope, in fact the optionality is a leftover from TP. It was required in ISO Pascal and FPC's ISO mode respects that.

SymbolicFrank

  • Hero Member
  • *****
  • Posts: 1313
Re: The future of Free Pascal
« Reply #178 on: June 17, 2016, 11:23:17 pm »
C++ is for masochists, who like to be encouraged to do things that harm them.

You have to do nearly everything yourself, because libraries are not portable at all.

The few standard libraries available all introduce their own and completely different syntax.

Everything is IDE and platform dependent.

And it is really hard to read, because the definition and syntax are context-sensitive. That's also why no two compilers agree.

Akira1364

  • Hero Member
  • *****
  • Posts: 561
Re: The future of Free Pascal
« Reply #179 on: June 19, 2016, 02:16:06 am »
Stumbled upon Free Pascal is very super mega ultra underrated. post few days ago, which seems relevant to this discussion.

C++ is а problematic, dead-end bloated language. ...
Why nobody seems to bother arguing with this nonsense? This kind of fanboyism and kind of religious bias towards is what shrinks this community even more.

When Delphi first appeared, the whole RAD approach coupled with a relatively sufficient language made it quite popular decades ago, but currently many other languages are quite enough and there are plenty of UI/RAD solutions out there. Really, there is nothing wrong with using C#, C, C++, Java or any other language these days (e.g. Swift) for application development and each of them, coupled with a huge collection of frameworks and libraries, are enough to work even on most challenging projects. Delphi, FreePascal / Lazarus work just fine as well, but since "Pascal" community is so small, it's difficult to convince companies and crowds to use a language that is unpopular and doesn't offer any significant benefits; in fact, at this point, no such language can possibly appear - existing languages already cover most needs, except, perhaps, for growing areas such as GPGPU, parallel computing, etc. - but these are pretty much saturated as well.

In this case, I think Lazarus as an IDE along with its LCL is the strongest bone. If Lazarus would switch to support C/C++ and LCL would be ported to that language as well - this, I think, *would* make it a killer product, at least for now. Designing UI outside of Delphi/Lazarus domain, although has become much easier, is still painful at times.

For instance, I can't help but to read posts regarding BGRABitmap with a bit of nostalgia attached to it - just to think of the things you could do in Delphi with TBitmap.Scanline some almost 20 years ago (and let's not forget about Graphics32 component too), and the whole thing of displaying more than 256 colors on the screen after DOS (please don't get me started with VESA) - these were some glorious days back then. I still remember walking like for two hours under the snow just to buy my first 3dfx Voodoo (was in Canada at that time) - it was so exciting! (Among many GPUs, Voodoo3, was the most exciting and pleasant to work/experiment with).

However, as almost every IT specialist who is old enough, would likely to experience this, even multiple times during lifetime, in computer world we have to realize that technologies that were so glorious many (and sometimes, maybe just few) years ago may become obsolete and we have to, un-learn and re-learn something entirely from scratch - and not necessarily because new tech is better than old one, but it's just happens. I'm not saying that this is necessarily going to happen (completely) with Delphi/FPC/Lazarus that some/all of us are using, but IMHO it's a tendency that becomes difficult not to see.

Hey, that's me! :D I somewhat over-simplified my points for the Reddit crowd, but the thread was 87% upvoted so clearly there's a decent number of people out there who see the benefits of FPC/Lazarus! I do also fully agree with you about the tendency of some Object Pascal programmers to have an unwarranted hatred of C++ (it's a fine, useful language, perfectly worthy of the popularity it has....a comment like the one "SymbolicFrank" made above is objectively disingenuous), however, the concept of adding some kind of C++ Builder-clone functionality to Lazarus is just a bad idea. The Borland C++ compiler is and always has been the absolute worst (just embarrassingly bad) commercial C++ compiler available (there's a very good reason Embarcadero recently scrapped it completely in favor of Clang), and everything about the C++ Builder IDE is just "ok, this sort of works, it's kind of like Delphi I guess, but not as good". Any attempt to imitate it would just be an attempt to imitate something that was mostly a running joke to begin with.
« Last Edit: June 19, 2016, 02:38:32 am by Akira1364 »

 

TinyPortal © 2005-2018