[erlang-questions] Erlang/YAWS vs Free Pascal/Xitami

Richard A. O'Keefe ok@REDACTED
Thu Mar 27 00:38:41 CET 2008


I wrote:
>> But third is most important:  what do you mean by "better"?

On 27 Mar 2008, at 12:18 am, Jilani Khaldi replied:
> You are right. Better is subjetive, so I add in the title "for my  
> application" and after I have given its main characteristics.

I don't quite agree here.
The choice of *criteria* may be subjective (although that is worth a  
debate
in itself; would we for one instance take seriously a claim that one  
program
was better than another because it contained more occurrences of the  
word
"chocolate"?), but whether one approach is better than another *given*  
the
criteria is definitely not subjective.

> I didn't mention time because it is not so important. I am writing  
> it in my spare time and it is not commercial => less stress.
> I know a lot better Object Pascal than Erlang and writing it in  
> Object Pascal is straightforward without the need or the help of  
> anyone. But I think this is a good occasion to learn Erlang  
> seriously writing a whole application than just continuing to play  
> with the language for years.

So we have two ranked criteria here:

  - learning an unfamiliar language seriously: important
  - time to market: not important

If it's important *enough*, then that answers the question completely:
writing the program in Pascal won't help you learn Erlang.
>
>
>> - Better = it is more reliable once written?
>>  I'd say Erlang every time; on the other hand these days there are  
>> web
>>  servers written in Haskell, so you might want the security of strong
>>  (polymorphic) typing as well as the safety of assignment-freedom.
> I already have tried Ada (GNAT) with AWS (https://libre.adacore.com/aws/main.html 
> ) and I like it but the problem is *long time compilation* of code.  
> FPC (Free Pascal Compiler) is an order of magnitude faster than GCC.

FPC is a neat tool.  Since they support the SPARC processors, it is a  
pity they
don't support Solaris, which is what I run on my SPARCs.  We now have  
another
criterion:

   - compilation speed: important

Of course, if you were just going to write the program once and get it  
right
in every way first time, compilation speed would not matter, so I  
suspect that
there are at least two other criteria:

   - time to detection for bugs: important
   - comfortable development environment that doesn't encourage bugs:  
important

For this, things like the Dialyser and QuickCheck and unit testing  
frameworks
are important.  So, for that matter, are the logging and debugging  
features
in Xitami.

Poking around at the Xitami web site, I clicked on the link to the FAQ.
Here's what I got:

    Not Found
    The requested URL /html/xitami/index13.htm was not found on this  
server.

    Apache/2.2.3 (CentOS) Server at www.imatix.com Port 80

I expect iMatix have some excellent but non-obvious reason for using
Apache instead of Xitami, just as www.erlang.org uses (an older  
version of)
Apache instead of Yaws.

It's not clear to me that you wouldn't be able to drive Erlang from  
Xitami.

>> - Better = runs in less memory on your machine?
>>  For an application that only needs one process, Pascal is likely  
>> to do
>>  better than Erlang here.  For an application that needs many  
>> processes,
>>  Erlang is likely to do better than Pascal.
> In fact, this point is very important seen the application has to  
> run (for the moment) on an obsolete computer and every single  
> application needs only one process. However, if an application needs  
> many threads Object Pascal handles them very well. At least, if I  
> need more power hardware is very cheap nowadays.
> Thank you for your comments!

When I said "processes" I was not referring to the process/thread  
distinction.
When you say that Object Pascal handles threads "very well", does that  
mean
	- thread stacks start tiny
	- thread stacks are automatically resized as needed
	- threads CANNOT interfere with each other's data
Because that's _minimal_ quality thread support.




More information about the erlang-questions mailing list