Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!news.luth.se!eru.mt.luth.se!bloom-beacon.mit.edu!gatech!howland.reston.ans.net!Germany.EU.net!Dortmund.Germany.EU.net!Informatik.Uni-Dortmund.DE!polly!wr From: wr@polly.informatik.uni-dortmund.de (Wilfried Rupflin) Newsgroups: comp.lang.beta Subject: Re: BETA questions Date: 25 Apr 1995 09:30:28 GMT Organization: CS Department, Dortmund University, Germany Lines: 193 Sender: wr@polly (Wilfried Rupflin) Message-ID: <3niffk$qik@fbi-news.informatik.uni-dortmund.de> References: <3jq90s$ojp@belfort.daimi.aau.dk> <3n5eht$m2i@fbi-news.informatik.uni-dortmund.de> NNTP-Posting-Host: polly.informatik.uni-dortmund.de Sorry, there seem to be problems with the gateway usergroup@mjolner.dk <-> comp.lang.beta again. So I found these articles only by chance now: In article <3n5eht$m2i@fbi-news.informatik.uni-dortmund.de>, nowias00@marvin.informatik.uni-dortmund.de (Mark Nowiasz) writes: |> Wilfried Rupflin (wr@polly.informatik.uni-dortmund.de) wrote: |> : >I am considering the use of the BETA programming language because of |> it's |> : >elegance and expressiveness but I still have some questions regarding |> BETA's |> : >maturity. |> |> : At University Dortmund, CS dept., it was decided to introduce BETA |> : as the main language for teaching starting with the last winter term. |> |> : The beginner's introductory lecture (called Programming I) was |> : run with BETA. Surprisingly we had neither didactical nor technical |> : problems (with over 300 students!). |> |> I am one of those students who was forced to learn BETA and ^^^^^^ OK, that's the problem of freshmen: you are 'forced' to learn some new language anyway. (And I claim that BETA isn't the worst choice by far!) Which language would you have preferred? |> had to cope with severe flaws of BETA resp. the Mjoelnir BETA Compiler : |> You should know that for the lecture an outdated version (2.5) of the BETA system was used. The lecturer, Prof. Doberkat, found the quality of this version fairly acceptable (compared to alternatives) and didn't like to have any risk when intoducing a new language and a new system to more than 300 students the first time ("never change a winning team ..."). So most of your complaints do not apply to the current version which is out for more than half a year by now. |> - The (only yet existing) Compiler did NOT correctly implement the BETA |> language (no repetitions of static elements, one has to use (* instead |> of {, etc. ) |> This is not quite correct: The compiler has a few restrictions currently (among others the one you quoted) but they are all documented in the compiler manual (and were mentioned in the lecture you [should have] attended). Everything else is implemented correctly. The other problem originates from the language book which is slightly outdated already. But again, these are minor points which are well documented and have been explained too. |> - The compiler gave out (relatively useless) warnings ("a run-time check |> will be generated here") I wouldn't say that such information is useless: they show just the points where in C++ e.g. you would have to use (unchecked) type casts. |> but stopped at real errors ("...stopped because |> of semantic errors") without any indication where the error occured. |> With the current release of the compiler this situation occurs *very* seldom. (I admit it was worse with the release you used.) My experience with the current release (3.0): o correct programs/fragments of virtually any size and complexity are compiled correctly o internal errors or wrong error messages occur very rarely and only in case of erroneous programs/fragments o error messages are in almost every case correct but due to the generality and orthogonality of the language also rather general and sometimes of little use for a novice user o run time error messages do not refer to a source line number, instead a call stack is dumped -- this constitutes no problem for typical real programs since the procedures are rather small and locating the faulty procedure is sufficient in most cases. But when you have several potential errors you may be lost with a longer pattern. This situation I had often when I prepared exercises which should demonstrate how compiler and RTS detect various erroneous constructs. Here line numbers would have been of much help. |> - BETA-programs are very large (> 250k even for a simple "Hello World" |> program) |> and REALLY slow (see below) |> I got about half the size for your Fibonacci program (with -nodebug): -rwxr-x--- 1 wr irb 131072 Apr 25 10:37 fibo* ... with debugging information it's a bit more: -rwxr-x--- 1 wr irb 163840 Apr 25 10:35 fibo* But as others have pointed out already: The design of BETA is not optimized for Hello or Fibonacci programs. With those 150k you get e.g. RT type checking (where necessary) and smart storage management including garbage collection. |> >How fast is BETA (executable speed)...compared to Eiffel and C++? |> |> IMHO very slow... i'll show you one example: |> |> I've had to program a pattern in BETA which would compute recursively the |> numbers of Fibonacci's algorithm. This program was compiled and started |> on a SUN 4. |> Simultanously, i implemented this function in C++ on my Amiga A-1200 (with |> a 68EC020 14MHzm without a FPU). |> Not only that the Amiga programm was smaller (5 k compared to >250k |> BETA) but |> ran significantly _faster_ than the BETA-program on the SUN (which is |> certainly |> a _lot_ faster then my Amiga) Again, BETA is not optimized for that sort of programming. Nobody would seriously attempt to write an efficient Fibonacci algorithm recursively (if at all), cf. below: In article <3nfoea$iiq@fbi-news.informatik.uni-dortmund.de>, nowias00@marvin.informatik.uni-dortmund.de (Mark Nowiasz) writes: [...] |> The recursive versions are the ones which I've compared, because the |> run-time |> of the iterative ones are nearly not measurable. ( << 1 second). Since BETA cannot use a simple stack allocation scheme for procedure activation records dynamic procedure calls are rather costly. But in BETA you have also static procedures which are extremely efficient. In article <3n5foo$m2i@fbi-news.informatik.uni-dortmund.de>, nowias00@marvin.informatik.uni-dortmund.de (Mark Nowiasz) writes: |> : Typical programs nowadays spend most of the time not in CPU but |> waiting |> : for |> : external events/devices (disk IO, user input, network ...). So even |> if |> : there |> : is a significant difference in the efficiency of compiled code you |> won't |> : recognize this difference. That's why I've taken as a reference the |> BETA |> : compiler which is also a program generated by the BETA compiler. |> |> IMHO may this kind attitude be responsible for large and inefficient |> programs |> and operating systems (like Windows >:-> ). |> Do you think those systems are inefficient because of bad code optimization? [...] |> |> These days, where GUIs are very complex and user-friendly, most of the |> program's code is dealing with the user's input / output and takes often |> quite a lot of time (in extreme cases most of the time ) |> (i.e. redrawing / refreshing / resizing windows resp. window's contents), |> so for most non-trivial problems efficiency considerations have to be taken. |> |> It's not very pleasant for an user to wait several seconds before a window |> is build or refreshed. That's just what I wanted to make clear: It's a smart overall program logik (avoiding unnecessary redraws e.g.) that makes an application fast for the user. Therefore we should be concerned first of all with the design and in the very end only with local code optimizations. If the design is right then also the overall efficiency is pretty good already. If it's not good enough then you should look after local optimizations. As it was said here already (cf. Jacob Seligmann's article <3kjr0e$bm4@belfort.daimi.aau.dk> there is no inherant reason why BETA programs should be inefficient -- only the current implementation isn't optimized yet. If you should be impatient, please let me quote Jacob: |> I believe that the next release of the Mjolner BETA compiler will |> contain significant speed enhancements, as have the previous releases. |> Meanwhile, remember that BETA contains an easy-to-use interface to C, so |> that you can code your 5% time-critical loops in regular low-level |> fashion and continue to enjoy the expressiveness and elegance of the |> BETA language and its libraries for the remaining 95%. Try the new (current) BETA system and you will see the difference. I hope you'll enjoy then to program in BETA (and forget that you were 'forced' to do so). Wilfried Rupflin *---------------------------------------------------------------* | Wilfried Rupflin | wr@irb.informatik.uni-dortmund.de | | | ___ | | Universitaet Dortmund | //// | | FB Informatik, IRB | UNI DO// | | Postfach 500 500 | Tel.: +49 231 755 2478 ___ //// | | D-44221 Dortmund 50 | Fax.: +49 231 755 2386 \*\\/// | | Germany | Telex: 822465 unido d \\\\/ | *---------------------------------------------------------------*