I used to use Delphi/Pascal as my main language. In the last decade or two I have been on a bit of a journey looking for a language that feels right to me. I used Haxe for quite a while but I felt Haxe fell into the trap of 'There's a Macro for that' (Macros can do anything, but ultimately enough macros make everyone programming in their own macro augmented language). JavaScript developed decent improvements (but cou…
> Begin End vs { } doesn't really bother me. but they don't really mean the same thing - {} defines a local scope, begin...end doesn't.
Why use Pascal?
131–140 of 516 posts
Re: Why use Pascal?
#132Earlier quoted context omitted.
> The LLVM backend is not officially supported by FP It used to be a separate project but these days is part of the main development branch. Though indeed the OS and CPU support is very limited. Also i agree about the micro benchmark comparison, they tend to exaggerate differences. FWIW in my own programs i never found Free Pascal's code generator to be inadequate. I do not remember the exact difference but last year…
I read other comments of people claiming the code generated by the LLVM backend was less than factor 1.5 faster than the one generated by the original backend, which is not worth the effort (and the humongous overhead and additional dependencies) from my point of view; but I'm still trying to find information about the specific optimizations done in the current FP compiler.
AFAIK there isn't any explicit documentation but the "toptimizerswitch" and "twpoptimizerswitch" (the latter is for whole program optimizations) types in the compiler define the available optimizations in globtype.pas and have the following values:
cs_opt_level1,cs_opt_level2,cs_opt_level3,cs_opt_level4,
cs_opt_regvar,cs_opt_uncertain,cs_opt_size,cs_opt_stackframe,
cs_opt_peephole,cs_opt_loopunroll,cs_opt_tailrecursion,cs_opt_nodecse,
cs_opt_nodedfa,cs_opt_loopstrength,cs_opt_scheduler,cs_opt_autoinline,
cs_useebp,cs_userbp,cs_opt_reorder_fields,cs_opt_fastmath,
cs_opt_dead_values,cs_opt_remove_empty_proc,cs_opt_constant_propagate,
cs_opt_dead_store_eliminate,cs_opt_forcenostackframe,
cs_opt_use_load_modify_store,cs_opt_unused_para,cs_opt_consts,
cs_opt_forloop
cs_wpo_devirtualize_calls,cs_wpo_optimize_vmts,cs_wpo_symbol_liveness
level1/2/3/4 are basically collections for some of the above and are enabled for -On where n is 1 to 4. You can enable optimizations explicitly with the -OoXXX (for per-module optimizations) and -OwXXX (for whole program optimizations). The -io and -iw parameters can be used to obtain the available names for these.I think the names are more or less self-explanatory, at least for the most part (not sure what "uncertain" does... which i think is appropriate :-P).
Some brief documentation (though very brief) is available in the programmer's guide:
https://www.freepascal.org/docs-html/current/prog/progch11.h...
Re: Why use Pascal?
#133Earlier quoted context omitted.
Strongly typed is orthogonal to dynamic and static typing. Python and Common Lisp are both "strongly" typed and dynamically typed. There's no reason to shun strong typing if you also like dynamic typing.
I would be curious to see references that claims that dynamic and static typing are orthogonal with strongly typed systems, as “strongly type” is rather ambiguous and the only reason I used the term was because that was how Pascal was promoted back in the day (or at least how was taught to me) From Wikipedia: In 1974, Liskov and S. Zilles defined a strongly-typed language as one in which "whenever an object is passed…
It is an unrelated concept to which type rules will be applied by the software at runtime or compilation time.
Re: Why use Pascal?
#134Earlier quoted context omitted.
Every so often a thread pops up about Turbo Pascal and I'm astonished as to how nice an IDE you could fit onto a 64K CP/M system. (See also comments above/below.)
Oh, it was very very nice. I still miss it today sometimes. Here are a few highlights: - Pressing F1 gave you reliably context sensitive help and the help content was really well put together. - The debugger was great and was basically what we now know from Eclipse or IntelliJ and completely not like gdb. It had the same keyboard shortcuts for stepping as IntelliJ still has today. - Computers in the 90s really did no…
Re: Why use Pascal?
#135I won't even bother clicking this click bait title. I learned Pascal as a sophomore in high school and by my senior year I knew I'd never touch it again. At the time it was a great introductory language but there's very little reason anyone should even be thinking about Pascal these days. Fun fact: I still have my old pascal files on floppy disks in a box somewhere with a not so thin layer of dust on them.
Re: Why use Pascal?
#136Earlier quoted context omitted.
Strongly typed is orthogonal to dynamic and static typing. Python and Common Lisp are both "strongly" typed and dynamically typed. There's no reason to shun strong typing if you also like dynamic typing.
how can Python be strongly typed if it doesn't enforce types for declared arguments? What is the value of this supposedly "strongly typed" Python's type system? class Object: pass def f(arg:int): print("type of arg = ", str(type(arg))) f(1) f(666.0) f("kek") f(Object()) type of arg = type of arg = type of arg = type of arg = and not a single error/warning thrown
let f x = x + 1;; (* What's the type?!?!? *)
Turns out that "strong typing" is a shitty phrase that people should stop using because it means too many conflicting things, and, consequently, means nothing. Static and dynamic typing have well-defined meanings, stick with those terms instead of ones that mean nothing.But for a demonstration (compare to Perl) try this in your Python REPL:
>>> 1 + "1"
Does it work? Probably not unless you futzed with the language implementation. In Perl it does, though. So to the extent that "strong typing" means anything, Perl is "weakly typed", Python is "strongly typed", and both are dynamically typed. It's an orthogonal characteristic of the type system and language from when type checking occurs.----------
EDIT: BTW, formatting code blocks on HN is really easy. Prefix each line of code with two space characters.
__Replace those _'s with spaces
The result is much cleaner than your comment: def foo(x):
return x + x
No extra newlines needed, more compact, easier for most people to read.Re: Why use Pascal?
#137I'm using Free Pascal for my 3D game engine (recent-ish screenshot[0]). For me there is really two main simple reasons: 1. Lazarus. A game engine is -waaay- more than just a 3D engine with the tools being a very important aspect. Lazarus and LCL provide a rich and well featured WYSIWYG RAD IDE and framework for making desktop applications. As a bonus Lazarus as an IDE (even ignoring the LCL framework) is very fast. 2…
Re: Why use Pascal?
#138Earlier quoted context omitted.
I read other comments of people claiming the code generated by the LLVM backend was less than factor 1.5 faster than the one generated by the original backend, which is not worth the effort (and the humongous overhead and additional dependencies) from my point of view; but I'm still trying to find information about the specific optimizations done in the current FP compiler.
> I'm still trying to find information about the specific optimizations done in the current FP compiler. AFAIK there isn't any explicit documentation but the "toptimizerswitch" and "twpoptimizerswitch" (the latter is for whole program optimizations) types in the compiler define the available optimizations in globtype.pas and have the following values: cs_opt_level1,cs_opt_level2,cs_opt_level3,cs_opt_level4, cs_opt_re…
I read somewhere that there are issues with higher optimization levels. Can you confirm that?
Re: Why use Pascal?
#139Re: Why use Pascal?
#140But Go has a modern runtime (with garbage collection), a modern ecosystem (with major libraries such as HTTP and TLS in stdlib) and an active community.