Hi,<br><br><div class="gmail_quote">2012/2/28 Lars <span dir="ltr"><<a href="mailto:noreply@z505.com">noreply@z505.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">Frank Church wrote:<br>
> 5. This requires an increase in the uptake of Pascal. I mean if a language<br>
> like D can get so much attention and have libraries being created for it<br>
> why can't Pascal which has been longer established.<br>
><br>
<br>
</div>Another language to check out is TutorialD by Date and Darwen, a pascal<br>
like relational database language. Another interesting one which there is<br>
almost no information about is "Pascal/R" which was a relational pascal<br>
that died quickly, but I don't know why.<br>
<div class="im"><br></div></blockquote><div>Certainly there are a lot of interesting languages.  I also find Oberon and Modula fascinating - the problem is that when you get into "research languages", actually getting them to interact with the rest of the system gets to be a burden.  For example, FPC now has ObjectiveC compatibility on Mac OS X, and FPC/Delphi can use C headers with trivial translations on all systems.  Making obscure API calls can be nearly impossible in some languages, or involve a large amount of work - the situation with having to translate header files is bad enough.  Add to that the availability (or lack of) native libraries to do routine tasks - This is something that languages like C and Java excel at, and basically doesn't exist for more research-oriented languages.  FPC is somewhere in the middle.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
<br>
> 6.  I guess one major shortcoming of Pascal is it is not immediately<br>
> identified with objects, like C. Can Free Pascal simply change its name to<br>
> Object Pascal<br>
<br>
</div>Not all of freepascal is object oriented, a lot of it is simple procedural<br>
and you have the option to use objects if you want. Java and Ruby make the<br>
grand mistake of making everything an object and forcing you to code in<br>
objects when you shouldn't have to. </blockquote><div><br></div><div>I agree here.  The idea that objects are automatically better for *everything* is a bit much.  If an object is a noun, a procedure is a verb.  Objects are useful when you need to encapsulate and track state, and are extremely useful in some areas (i.e. GUI operations, tracking handles, etc.), but of little value in certain other areas.  </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">C# the ugly java rip off language also<br>
forces you into objects and classes.  </blockquote><div><br></div><div>To be share, C# is better than Java in some ways, despite being a rip-off.  It has the advantage of hindsight, so they could do some things differently than Java and Delphi.  (We the main designer of C#, right?)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If IntToStr was welded in to some<br>
object and I had to create an "IntToStr object" before calling IntToStr,<br>
that would suck major.<br>
<br></blockquote><div>Agreed.  I would assume that should be a class method, at least.  The way it works in Java, iirc, is that the "toStr" method would be a method of the Integer class.  Obviously, making even the lowest level types into Objects will exact a performance penalty.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
What would be nice is some actual innovation in programming languages<br>
instead of reinventing C++ over and over again.  I think what languages... ....</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">a database table that you can create easily in your language instead of</blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
resorting to embedding SQL strings into your program.<br>
<div class="im"><br></div></blockquote><div>I am an ABAP programmer by day, and I have to say that although I find ABAP primitive in some respects (f.e., no WITH ... DO functionality, annoying spacing rules, etc.), the data type, library, and most notably, database functionality is a dream.  It's too bad that the language is heavily tied to SAP.  In ABAP, you can declare variables to be of the type of certain table fields, and the compiler will automatically match that.  You can declare new types in the data dictionary, and then use them in your programs.  In addition, you can use SQL as part of the language itself, rather than as a string literal - which means tables, etc., can be checked at compile time.  I could go on, but the point is that although the language is lacking some bullet-point type features that all the cool kids have, it is very practical for developing business applications in.  On the down side, you basically can't use ABAP without a huge database and BASIS runtime installation - it wouldn't be good for desktop apps unless you have gigabytes to devote.</div>
<div><br></div><div>I have tinkered with adding some of this basic functionality to FPC in the past, but it would require significant compiler changes.  I do have an ABAP utility language for FPC though which handles a lot of ABAP functions in FPC (translate(), etc.) to make porting easier, as I often prototype in FPC offline and then convert to ABAP.</div>
<div><br></div><div>As for using database tables, I think FPC could stand to have more included data types for handing such things without a database.  We have dynamic arrays, which can't even handle a deletion of an item in the middle, and then we have StringList.  As soon as people want something like DualStringList, they resort to using the Object field of StringList and all kinds of Typecasting hacks.  Generics solves this problem to a degree, but is still a relatively new feature, and perhaps not the solution for everything.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> Honestly I think the name is probably the biggest problem if in an era of<br>
> objects everything it is not associated with Pascal due to its age and<br>
> past.<br><br></div></blockquote><div>Well ObjectPascal has been around since the early 90s at least, and from an end-user point of view, pascal became primarily Object Oriented with TurboVision and later Delphi in the mid 90s - so anyone who doesn't know about that is severely misinformed.  I am not sure that changing the name will make up for that.   </div>
<div><br></div><div>FPC still keeps compatibility with real mode and non-OOP programming - and there is no way to change that any time soon even if we wanted to, so I am not sure what you are suggesting.  For example, most of the system/sysutils units is not OOPs.  In order to make things work, we have to call OS level features and kernel ABIs, which are almost never OOP.  (Except on Mac OS for some things).  </div>
<div><br></div><div>I think that if we suddenly had a huge budget in terms of money or developer time, there would be other areas we would be better off investing in - like making threads easier and more reliable to use.  I have to admit to being jealous when I see stuff like this in other languages:</div>
<div><br></div><div>Run_in_background (save_file(), update_gui());</div><div><br></div><div>Probably before that, I would push for proper UTF8String support, so that functions like Copy() return the correct characters instead of still thinking in byte mode.</div>
<div><br></div><div>In the end, everyone here I expect loves Pascal, or we wouldn't be on this list, but expecting it to suddenly become super popular tomorrow is probably not realistic - on the other hand, think of it as your secret weapon.  While everyone else is struggling with doing simple string operations and pointer issues in C++, include file issues in C, OCX registration issues in classic VB, the common runtime version mismatch issues in Java, and the 12 versions of .NET that seem to have to be present on any system in order for .NET programs to function - you can have a single set of source code that compiled to Windows, Linux, and Mac OS - even in GUI programs.  You can also have the low level power of C when you need it, and the ease of higher level programming languages and OOP when it's useful.  </div>
<div><br></div><div>With newer versions of Delphi and FPC, they have both been catching up in terms of compiler level features:  Anonymous methods, generics, safer object references, helper classes, etc.  The only thing that doesn't really fit neatly into the ObjectPascal model is garbage collection, and that's largely a non-issue with things like Try..Finally and TComponent. (Delphi.NET I suppose merges OP with garbage collection somehow or another).</div>
<div><br></div><div>If you want to convince people to use FPC and are having issues, you should ask them what features, exactly, they are looking for.  Chances are that FPC has them.  (If they want a functional language, though, then you're out of luck).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Objects everything.. yuck.. I still like simple procedural code for<br>
teaching people and for doing quick prototypes, I think one of the biggest<br>
mistakes of the industry is obsession with objects and not enough<br>
education about relational techniques (<a href="http://www.dbdebunk.com" target="_blank">http://www.dbdebunk.com</a>)<br></blockquote><div><br></div><div>Procedural models, OOP models, and relational models all serve different needs.  Certainly it would be convenient if FPC had native DB integration. (i.e. compiler level instead of library level).</div>
<div><br></div><div>Thank you,</div><div>    Noah Silva</div><div> </div></div>