Back to General and Gameplay Programming

Beyond C/C++/C#/Java

antareus · 2003-09-12T19:54:38

Great quote from my comparative languages teacher: "I''m here to try to teach you to not take computer languages seriously." Now when I heard that I knew I was one of the ones that takes them seriously. It borders on religious wars with a lot of people. You get it ingrained that "C++ is the way" and you lock yourself into imperative/half-assed OO (single dispatch comes to mind) constructs, when in reality all you''ve done is buy into the popular opinion that C/C++ is the way to go on most projects. No, it isn''t hype, but at the same time it isn''t much better. I can only hope that the time I''ve spent in C++ does not hinder me greatly when it comes to learning ML and Prolog. The past few days I''ve (outside of class) looked at various different languages such as Eiffel and O''Caml. Eiffel looks really neat and amazingly clean, as does O''Caml''s blend of imperative/functional/OO into one language with decent syntax. I noticed they were both garbage collected, yet O''Caml''s performance is said to be very competitive with raw C. Has anyone worked on either of these languages? I''d be interested to know what you thought of them for larger projects.

General and Gameplay Programming Programming

Started by antareus September 03, 2003 01:37 PM

66 comments, last by antareus 20 years, 7 months ago

CaptainJester

523

September 11, 2003 06:39 AM

quote:Original post by haro
Lisp''s development was 100% guided by the machine architecture it was going to be running on. Without an intimate knowledge of the target machine''s architecture Lisp obviously would never have come to exist. As much as academia loves to portray programming languages as beautiful formal problem descriptors, they are nothing but a way to interface with a PC as mentioned earlier..

Man, talk about trying to twist a quote to your own advantage. Of course he is going to have to worry about architecture when he has to write a compiler to convert the source to a machine readable format. He is going to have to pick a machine to start with. That doesn''t mean he sat and studied the IBM 704 to create the language.

First make it work,
then make it fast.
--Brian Kernighan

"The problems of this world cannot possibly be solved by skeptics or cynics whose horizons are limited by the obvious realities. We need men and women who can dream of things that never were." - John Fitzgerald Kennedy(35th US President)

"None of us learn in a vacuum; we all stand on the shoulders of giants such as Wirth and Knuth and thousands of others. Lend your shoulders to building the future!" - Michael Abrash[JavaGaming.org][The Java Tutorial][Slick][LWJGL][LWJGL Tutorials for NeHe][LWJGL Wiki][jMonkey Engine]

SabreMan

504

September 11, 2003 06:48 AM

quote:Original post by haro
Assuming you are not playing word games and going to retort that the entry point is a function in of itself, this is not at all as implausible as it might sound.

So you don''t need assembly language to teach about functions. If they can''t understand the purpose of functions in a language which directly provides for them, then I suggest its not the language being used that is the difficulty. However, you seem to have short-circuited the step that involves considering all the possibilities.

quote:Original post by haro
Not attempting to mudsling or flame, but that''s really just completely wrong.

What you''ve quoted is about the implementation of Lisp. Unfortunately, I earlier used the word `development'' where I really meant `design''. There is something about what McCarthy was designing in the document you linked to:

quote:
Apart from consulting on the geometry program, my own research in artificial intelligence was proceeding along the lines that led to the Advice Taker proposal in 1958 (McCarthy 1959). This involved representing information about the world by sentences in a suitable formal language and a reasoning program that would decide what to do by making logical inferences. Representing sentences by list structure seemed appropriate - it still is - and a list processing language also seemed appropriate for programming the operations involved in deduction - and still is.

However, this is all circumstancial. Intimate knowledge of the IBM 704 will not help you write good Lisp programs, just as intimate knowledge of the IBM 80x86 will not help you write well-structured C++ programs.

daerid

354

September 12, 2003 01:25 AM

The design and implementation of a programming language are completely separate beasts. It''s why most compilers are written with a front-end and a back-end. The front-end doesn''t give two shits about the final architecture that the code will be running on. It''s more worried about the syntax and semantics of the language.

A programming language is ultimately just a method of describing actions and the decision path used to perform those actions. There''s no need to clutter up the design of a good language with details about specific hardware architecture. Let compiler writers deal with that.

daerid@gmail.com

flangazor

516

September 12, 2003 04:49 AM

daerid, that is one of many strategies. For some languages, it makes sense to note the hardware it runs on. e.g. occam2 runs on an INTUOS chip because of its parallel processing features.

thona

100

September 12, 2003 12:23 PM

quote:Original post by flangazor
daerid, that is one of many strategies.

No, it is THE Staategy in the last years. You astand against the industry - who is smarter?

quote:For some languages, it makes sense to note the hardware it runs on. e.g. occam2 runs on an INTUOS chip because of its parallel processing features.

Which is perfect in the BACKEND. Once you have verified that the syntax is correct, have built your syntax node graph, have made the optimisations on it that you CAN (dead code elimination, taking precomputes out of a loop, for example).

THEN you start bothering about tha hardware.

The hardware, parallel or not, is not at all interesting as long as you dont even know the syntax is correct. And once you get into generating the machine code and optimising the stuff, you dont want to deal with test files to parse anymore.

RegardsThomas TomiczekTHONA Consulting Ltd.(Microsoft MVP C#/.NET)

flangazor

516

September 12, 2003 01:25 PM

quote:No, it is THE Staategy in the last years. You astand against the industry - who is smarter?

Good one.

(It was a joke, right?)

quote:The hardware, parallel or not, is not at all interesting as long as you dont even know the syntax is correct. And once you get into generating the machine code and optimising the stuff, you dont want to deal with test files to parse anymore.

We are discussing language design versus implementation. This is not a discussion of compiler construction strategies. Obviously a retargetable compiler is a nice thing for retargetable languages. My beef is which daeride''s seeming assertion that all languages should be retargetable. This is flawed thinking in my opinion.

It doesn''t help making a parallel language on hardware that offers nothing to make such a language useful. Such a language should/would be designed for hardware that supports such features.

daerid

354

September 12, 2003 06:15 PM

I wouldn''t go so far as to say that all languages should be retargetable.

x86 assembly, for example, is a language which isn''t, and by definition, can''t be.

However, a general purpose programming language should most definitely NOT be designed around a specific hardware structure.

daerid@gmail.com

Cedric

158

September 12, 2003 07:54 PM

Bah, it depends on the kind of feature that you want. If optimization is a prime concern, I agree with flangaznor.

And, to some extent, it can be argued that a lot of languages were designed with the hardware in mind. If C or C++ are not garbage-collected, it is because of hardware concerns, isn''t it (i.e.: processors weren''t fast enough).

Beyond C/C++/C#/Java

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Beyond C/C++/C#/Java

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines