OSDev.org

Heres my opinion on what a language/compiler should do

* It should be purely object orientated.
-- This means all variables are also objects.

* DCI not classes based objects.
-- classes work well for representation though.

* "Code Contracts" http://en.wikipedia.org/wiki/Design_by_contract

* Exception handling made simple.

* Strong language to express your intentions. (Clarity)

* Information should never be lost
-- Optimisations should be coded separately.

mike brown

IMVHO, "fail" right there. "Pure" is for the lab.

I do love Eiffel, But it really does feel like its ideas are more important that its implementation.

Average everyday programmers are what higher-languages are for, And i believe they should be limited or controlled into following best practises.

"Object-Orientated" is a form of organisation. There is no reason why all programmers code can not be organised with objects.

Classes do not make good objects, They produce fragmented code which gets scattered between multiple semi-related objects.

Mike Brown

Learn Haskell

Applications have long since developed passed the feasibility of being made in a purely functional manner. Programmers mental scope is just too small to see a project as a whole.



I never trust everyday programmers to do the right thing. To change classes into something simple and easy to use is pretty hard in current languages, so they just dont bother

mike brown

Apparently berkus should've placed a </sarcasm> tag there.

Yes, "pure" functional programming doesn't cut it anymore.

Hint #1: "Pure" object-oriented programming isn't that much better.

Hint #2: It very much depends on the skill level of the programmer(s) doing the work. I prefer well-done C over haphazard Java anytime. I prefer well-done C# over haphazard C++, I prefer well-done Perl over haphazard C, I prefer well-done Java over haphazard Python. I prefer any well-done X over any haphazard Y, with the possible exception of Brainfuck and Assembler (the former being haphazard by definition, the latter appearing haphazard either to the programmer or the CPU - and, sometimes, both ).

In the end, it is about how much the language enables the programmer to "do the right thing". "Pure" paradigm languages usually require the programmer to jump through a couple of hoops to satisfy the paradigm, which doesn't benefit coding style.

I admit that, on the other end of the scale, powerfully enabling languages can make it very hard to find the right thing to do. (Point in case: C++.)

I think a better question is why do we need the ones we have?

A computer language to me is just a barrier between me and the computer. They don't represent how i think, and they don't represent how the computer thinks.

They're better at representing our thoughts than machine code. I don't know about you, but I definitely prefer writing in (a limited subset of) real words.

Imo i think languages have aimed at implementation, and so the subset of real words represent that train of thought.

We've (hopefully) all realised that design is king. the problem comes when people think code is design. our current languages haven't helped with that, shoe horning the two together.

I hope one day design is what we write in, and implementation gets hidden away or better, automated.

Please explain why don't we need the ones that already exist?



I could not agree more that many people myself included think this way.

it was the reverse of the why do we need a new language. if there is so many already, imo they can not be solving the problem at hand.

Sorry. are you saying that you think code = design?

Yes at the beginning of things. But now I know that design = many others things other than code.

Why do we need more OSes then? I think the answer will be the same as why do we need more languages. And BTW, Id love a forum for VM & Language development. And code is NOT equal to design, it is merely a way of expressing ones design to the computer.

Been looking for this myself. I'll buy compilerdev.org and some hosting if anyone will help me build it?