Ideal computer language from scratch?
Evenbit
different languages and some of the things I like and dislike about
these languages.
Basically, my thoughts circle around this question:
How would you go about designing an Ideal computer language from
scratch?
Since this is an assembly NG, I guess this translates to:
How would you go about designing an Ideal assembly language (or
perhaps, an Ideal high level assembler) from scratch?
What are the most important elements to have in a language?
What are some of the most troubling aspects of existing languages?
Would your design center (at least partially) on avoiding these trouble
spots?
Would the design favour programmer productivity or processing
efficiency?
Of course, the list goes on... And, as one answers these questions,
they invent their very own language.
Nathan.
Chew...@austarnet.com.au
Evenbit wrote:
Hi Nathan,
> For the last few days, I've been pondering the simularities between
> different languages and some of the things I like and dislike about
> these languages.
> Basically, my thoughts circle around this question:
>
> How would you go about designing an Ideal computer language from
> scratch?
I would think about the things I like and dislike in other languages I
know and have worked with... Personally for me, that's about 6x
flavours of BASIC, C, Assembly (x86, AMD64, 6502/6510, and some 68K),
Pascal (mainly Borland) and some PHP/Perl as well as windows scripting
(vbscript).
> Since this is an assembly NG, I guess this translates to:
>
> How would you go about designing an Ideal assembly language (or
> perhaps, an Ideal high level assembler) from scratch?
http://chewy509.atspace.com/b0.html
> What are the most important elements to have in a language?
Being most a low-level hobbyist, then solid control over the machine
state is desirable. As well as support for most common programming
methodologies (procedural, OOP, support for object files, linking with
objects files created using another langauge/compiler). Support tools
would also be a factor high on the list, eg integration into my
perfered OS, IDE, toolchain, etc.
> What are some of the most troubling aspects of existing languages?
> Would your design center (at least partially) on avoiding these trouble
> spots?
The level of abstraction between the language and the machine, and by
creating a machine dependant language, would resolve that issue.
> Would the design favour programmer productivity or processing
> efficiency?
Since when they these two concepts been mutually exclusive? b0, since
is machine dependant (AMD64 in it's case), provides the programmer the
ability to focus on performance, while using a language that is easy to
grasp... (well I think so at least)
> Of course, the list goes on... And, as one answers these questions,
> they invent their very own language.
Again see: http://chewy509.atspace.com/b0.html
--
Darran (aka Chewy509) brought to you by Google Groups!
sevagK
> For the last few days, I've been pondering the simularities between
> different languages and some of the things I like and dislike about
> these languages.
> Basically, my thoughts circle around this question:
>
> How would you go about designing an Ideal computer language from
> scratch?
I think I would go with something like a compiled form of Java without
as much emphasis on OOP. Keep it clean and enforce a strict
programming discipline.
> Since this is an assembly NG, I guess this translates to:
> How would you go about designing an Ideal assembly language (or
> perhaps, an Ideal high level assembler) from scratch?
There is no such thing! There are as many ideal assembly language
designs as there are assembly programmers. Assemblers are fun to work
with and my chosen tools for my hobby, but IMO, an "ideal" assembler
has to either target a low-level dicipline (eg: GoAsm) or a high-level
dicipline (eg: HLA).
> What are the most important elements to have in a language?
-Consistency. There should not be syntactical changes at unexpected
places or lax rules on expressions and conventions.
-Type checking. at 100% user control, overridable. Eg: have native
"sized" types that accept any types of specific size, or have specific
types (native or user defined).
-Readability. Here is where HL control structures shine. Everything
should be neatly stacked so that the beginning and end of a "section"
of code are easy to find, along with all places that code can fall
through.
> What are some of the most troubling aspects of existing languages?
> Would your design center (at least partially) on avoiding these trouble
> spots?
I suppose it would, though I'm not much of a language designer. My
experiences lies in a couple of scripting engines: a simple "make"
script processor and the Arayna IF game engine.
For me, languages that are not strong on the "most important elements"
or one's that don't target a specific programming discipline fall off
the bottom of my list real quick.
> Would the design favour programmer productivity or processing
> efficiency?
It would favour a compromise.
> Of course, the list goes on... And, as one answers these questions,
> they invent their very own language.
>
> Nathan.
Our very own fictional language :)
-sevag.k -=Kain=-
www.geocities.com/kahlinor
柑\/b
>For the last few days, I've been pondering the simularities between
>different languages and some of the things I like and dislike about
>these languages.
>Basically, my thoughts circle around this question:
>
>How would you go about designing an Ideal computer language from
>scratch?
>
>Since this is an assembly NG, I guess this translates to:
>
>How would you go about designing an Ideal assembly language (or
>perhaps, an Ideal high level assembler) from scratch?
i should think on
the number of registers (?), the size of registers (32 bits), the
operations among registers, how to operate on 16bits data and
on 8bits data and how operate on arrays; how represent real numbers.
then i should implement "#" as symbol for jumps and to build the
language like that i have now
>What are the most important elements to have in a language?
it is "the easily to read" the power for make "to see"
programming is "to see" it is not hide
the assembly language is good because it is easy and
if there is an error it is show soon
>What are some of the most troubling aspects of existing languages?
the difficult for catch errors
>Would your design center (at least partially) on avoiding these trouble
>spots?
use assembly or implement all the memory of a program in "the heap"
and then run a routine for check if there is some of out of bound
write in the heap memory
>Would the design favour programmer productivity or processing
>efficiency?
i don't know
>Of course, the list goes on... And, as one answers these questions,
>they invent their very own language.
C language is where many people start for build languages
>Nathan.
JGCASEY
Evenbit wrote:
...
> What are the most important elements to have in a language?
Enough people using it.
> What are some of the most troubling aspects of existing languages?
Too many of them.
...
> Of course, the list goes on... And, as one answers these questions,
> they invent their very own language.
Yes, they create their very own language to add to the ever growing
Tower of Babel of computer languages. We have enough languages
already.
The most unimaginative thing you can do once you learn a computer
language is to write yet another one to add to the confusion.
IMHO :-)
--
JC
Dragontamer
Evenbit wrote:
> For the last few days, I've been pondering the simularities between
> different languages and some of the things I like and dislike about
> these languages.
> Basically, my thoughts circle around this question:
>
> How would you go about designing an Ideal computer language from
> scratch?
>
> Since this is an assembly NG, I guess this translates to:
>
> How would you go about designing an Ideal assembly language (or
> perhaps, an Ideal high level assembler) from scratch?
Just as you are doing: ask everyone what languages they like and then
try and combine features.
> What are the most important elements to have in a language?
Userbase: you can't control this one really.
Size: The langauge should be as small as possible. Think C++: so
massive
no one person is expected to know all aspects of the langauge :-/
Library Support: Should be able to interphase with GTK+, OpenGL, if
not directly then in theory. Basically, a binding to C libraries in
some sort of
way. (scripting language if necessary)
Macro features: even high level languages can benifit from a rich and
powerful standard macro set.
> What are some of the most troubling aspects of existing languages?
> Would your design center (at least partially) on avoiding these trouble
> spots?
Size again comes in here: most languages don't have the problem of
being too small, but there are many languages that can be felt are "too
large"
> Would the design favour programmer productivity or processing
> efficiency?
The language should innately show how efficient the program is going
to be; after that, processing efficiency will simply come after that.
--Dragontamer
Rod Pemberton
"Evenbit" <nbake...@charter.net> wrote in message
news:1140225418.7...@f14g2000cwb.googlegroups.com...
> For the last few days, I've been pondering the simularities between
> different languages and some of the things I like and dislike about
> these languages.
> Basically, my thoughts circle around this question:
>
> How would you go about designing an Ideal computer language from
> scratch?
...<snip> continuing thoughts...
> How would you go about designing an Ideal assembly language (or
> perhaps, an Ideal high level assembler) from scratch?
...<snip> continuing thoughts...
> What are the most important elements to have in a language?
I'd end up with C, PL/1, or FORTH. I've programmed in about fourteen
different languages over the years, including a number of assembly
languages, and those are my favorites.
The _MOST_ important thing to me as a programmer is the ability to use
addresses (or pointers). Languages with out them are typically "crippled."
Pascal is very similar to PL/1, but no pointers. Java is very similar to C,
but no pointers. It is _very_ difficult to program certain things without
pointers. Fortunately, this is usually easy in assembly.
The second most important thing to me is that the language have ability to
do both structured and unstructured programming. By structured programming,
I mean a block has a single entry and exit point, you can't jump out of
loops, etc. PL/1 has very few unstructured elements, but, in C, there are a
number of them, or at least some that can be used in both ways. This
greatly eases porting of code from unstructured languages.
As for assembly languages, NASM has one of the easiest syntaxes to learn for
IA-32. It's syntax has very few special constructs or operators. And, it's
syntax closely follows the byte order of the generated instructions. This
can be important for some people (like me). GAS (Gnu ASsembler) or the asm
directives of GCC are much harder to learn, but, it's ability to control how
the assembly language is integrated with C is superb.
One of the issues I've run across lately with certain assemblers, is that
they can't generate _all_ the instructions that the CPU uses. This has
caused me the most grief lately.
Rod Pemberton
\~o/~///annabee
Pascal do have pointers.
var APointer : Pointer
AInteger : Integer;
begin
APointer := @AInteger;
APointer^:= 2 ;Assign 2 to AInteger
end;
Rod Pemberton
"\~o/~///annabee" <f...@szmyggenpv.com> wrote in message
news:1140327113.2...@g14g2000cwa.googlegroups.com...
<repost>
Pointers in Pascal are very limited compared to pointers in PL/1 or C. They
are restricted or type safe. IIRC, Niklaus Wirth made them explicitly bound
to the datatype which isn't true in PL/1 or C, and they can't be assigned an
absolute memory address. Also, IIRC, one can't do pointer arithmetic in
Pascal. Basically, pointers in Pascal are safe, limited, useless, and
really shouldn't be called pointers, but numerical identifiers.
Rod Pemberton
\~o/~///annabee
C. They
are restricted or type safe. //
Not in the pascal I used todo.
//
IIRC, Niklaus Wirth made them explicitly bound
to the datatype which isn't true in PL/1 or C, and they can't be
assigned an absolute memory address.
//
Not in the pascal I used to do. :D
// Also, IIRC, one can't do pointer arithmetic in
Pascal.
//
One can in the one I used. :D :D
//
Basically, pointers in Pascal are safe, limited, useless, and really
shouldn't be called pointers, but numerical identifiers.
Rod Pemberton
//
You can do all those things in pascal. (The versions I have used).
However, I agree that using pascal, when there is asm available is not
a good option. Asm is 100 times easier todo then pascal, and pointer
aritmetic is 1000 times easier in asm.
Chew...@austarnet.com.au
> //Pointers in Pascal are very limited compared to pointers in PL/1 or
> C. They
> are restricted or type safe. //
>
> Not in the pascal I used todo.
Hi Wannabee,
Out of interest, which pascal implementation was that?
You need to understand that many earlier implementations lacked
sufficient or even complete pointer functionality... ISO Pascal (ISO
7185) has full pointer functionality included, however many popular
implementations predate the standard (IIRC the standard was released in
1990), or even in light of having a standard many implementors did not
(or would not) provide full ISO level compatibility.
The reason why pointers are so easy to use in assembly, is that they
are essential to the operation of the CPU, due to the limited number of
CPU instructions and constructs available. Assembly would be damn
difficult if you didn't have pointers!
Like many great ideas, there seems to be a plague of 'professionals'
denoting the use of pointers as heresy, and should be placed into the
same category as the 'goto' statement in many languages (eg, to be
avoided at all cost). However, IMHO this is only because of a lack of
understanding of pointers and the ability to use pointers correctly by
the larger community... How many security vuln's are because some
programmer forgot to do bounds checking during pointer operations? For
assembly programmers, bound checking is (or should be) second nature
when using pointers, but for most HLL programmers it's an often
misunderstood field even if the programmers knows that bounds checking
is even required when using pointers. Hence why IMHO most 'modern'
langauges don't have pointers.
\~o/~///annabee
//
Hi :D
//
Out of interest, which pascal implementation was that?
//
Various versions of Borland Turbo and Object pascal, including some
versions for windows, like the Delphi 1.0, 3.0, 5.0.
But all this is fading from memory now. Its been 2 years since I used
Delphi, activly.
//
You need to understand that many earlier implementations lacked
sufficient or even complete pointer functionality...
//
The way to do artimetic with pointers, in Delphi is awkard, compared to
asm, but fully possible via typecasting. IIRC.
Integer(CPointer)^ := Integer(APointer)^ - Integer(Bpointer)^ + 4
or something like this.
Can also be done in an asm statement
asm
mov eax APointer
sub eax BPointer
add eax 4
mov CPointer eax
end:
I may no longer remember the exact syntax.
I also no longer have Delphi installed, so I cannot confirm the syntax.
What later versions of Delphi has, is the NO NEED to use the ^ sign on
pointer member assignments, when the pointer have a type.
type
PRect =^TRect
TRect = record
left, top, right, bottom : integer
end;
var
width : integer;
Rect : PRect;
begin
Rect := New(Prect)
Rect.Left := 100
Rect.Right := 200
AWidth := Rect.Right - Rect.Left
end
//
ISO Pascal (ISO
7185) has full pointer functionality included, however many popular
implementations predate the standard (IIRC the standard was released in
1990), or even in light of having a standard many implementors did not
(or would not) provide full ISO level compatibility.
//
ISO standards, or standards at all, for a language makes little sense
to me. The only things that should be made standard, are the things
that can never change.
Each time I see some happy-person conform with some standard :D Thats
when I know its a girly. A Lumberjack sort of :D :D :D
//
The reason why pointers are so easy to use in assembly, is that they
are essential to the operation of the CPU, due to the limited number of
CPU instructions and constructs available. Assembly would be damn
difficult if you didn't have pointers! //
Programming, without the use of adresses, is meaningless. Yes, they are
essential to programming. Yes they are easier to deal with then the
encapsulation madness, and asm is 1000 times easier to program with
than HLL. And it gets easier and easier todo asm with time, whereas the
exact oposite is seems true for HLLs.
//
Like many great ideas, there seems to be a plague of 'professionals'
denoting the use of pointers as heresy, and should be placed into the
same category as the 'goto' statement in many languages (eg, to be
avoided at all cost). However, IMHO this is only because of a lack of
understanding of pointers and the ability to use pointers correctly by
the larger community...
//
Yes. Once the programmer starts with asm, with a _good_ assembler, it
pretty soon becomes rather simple todo pointers (addresses). To bad
that asm seems to be almost impossible todo, from a hll perspective,
because of the many really useless assemblers around. But with a really
good one, asm is many times easier, after just a few months that hll
could ever become. I used todo only pascal, and sometimes flirting with
a bit of inline asm. I found it also to be "dangerous" and "slow"
process. Because I never really took time to learn it, by using it
everyday.
//How many security vuln's are because some
programmer forgot to do bounds checking during pointer operations? For
assembly programmers, bound checking is (or should be) second nature
when using pointers, but for most HLL programmers it's an often
misunderstood field even if the programmers knows that bounds checking
is even required when using pointers. Hence why IMHO most 'modern'
langauges don't have pointers. //
IMO, theres little need for boundchecking in asm. Boundchecking is
something you need when you do not know what you are passing. In asm,
in most cases, you really do know what is expected for a procedure. So
you almost never need to boundcheck anything.
(You check the data on input, from user, but not much inside the
application).
Sure, bugs appear each time one makes an error. But the more errors one
is able to make, the faster one learns. The biggest problem with HLL
programming is the baseless thinking that one can develop a language so
to avoid making errors.
The security hysteria the later month/years are just part of the usual
FAD. Each now and then, some FAD words turns up. Like security, like
Threads, Like Hyper this and Hyper that. Its all bullshits. It means
nothing to me. Its all propaganda to keep the little lams busy.
They, the OS makers, could implement absolute security in an OS in like
half an hour if they wanted to. They just dont care, when they can sell
both the illusions, and the supposed cure.
Betov
@g14g2000cwa.googlegroups.com:
> Like many great ideas, there seems to be a plague of 'professionals'
> denoting the use of pointers as heresy, and should be placed into the
> same category as the 'goto' statement in many languages (eg, to be
> avoided at all cost). However, IMHO this is only because of a lack of
> understanding of pointers and the ability to use pointers correctly by
> the larger community...
You are right on the point with "goto" banishment
being the same attitude. Both try disesparately
to "hyde" the Processor level, and completely fail
to understand the problem they try to "hyde" instead
of solving.
Goto, for example, is not *Goto*, at all. They ment
"Spahetti Style Programming", and they generalized
abusively to "Goto", which does not make any sense
as, anyway, the _Code_ achieves into "goto"s every
here and there.
But, even from the root, the intention was wrong,
because "Spahetti Programming" is bad only when it
is abusive, that is, used over some point of
confusing organization. As i have demonstrated,
in B_U_Asm, this is even possible to find out some
particular cases, where "Spahetti Programming" is
even easier to read that HLL Constructs.
It was just a matter of self control. Not a matter
of abuse, or of banishment.
> How many security vuln's are because some
> programmer forgot to do bounds checking during pointer operations? For
> assembly programmers, bound checking is (or should be) second nature
> when using pointers, but for most HLL programmers it's an often
> misunderstood field even if the programmers knows that bounds checking
> is even required when using pointers. Hence why IMHO most 'modern'
> langauges don't have pointers.
Bound Checking is absurd: If a Programmer does not
know what he is doing, he cannot be doing Assembly.
Generaly speacking, the experience shows that securities
are useless evil, most often trying to solve problems
that do not even exist. Typically: Names Conflicts in
a Compiler prevention, that is nothing but suppressing
an occasional significative helpful indication of bad
Naming.
Betov.
柑\/b
<f...@szmyggenpv.com> wrote:
[]
>IMO, theres little need for boundchecking in asm. Boundchecking is
>something you need when you do not know what you are passing. In asm,
>in most cases, you really do know what is expected for a procedure. So
>you almost never need to boundcheck anything.
>
>(You check the data on input, from user, but not much inside the
>application).
>
>Sure, bugs appear each time one makes an error. But the more errors one
> is able to make, the faster one learns. The biggest problem with HLL
>programming is the baseless thinking that one can develop a language so
>to avoid making errors.
>The security hysteria the later month/years are just part of the usual
>FAD. Each now and then, some FAD words turns up. Like security, like
>Threads, Like Hyper this and Hyper that. Its all bullshits. It means
>nothing to me. Its all propaganda to keep the little lams busy.
>They, the OS makers, could implement absolute security in an OS in like
>half an hour if they wanted to. They just dont care, when they can sell
>both the illusions, and the supposed cure.
i'm not agree; if a language can minimize errors (for example if the
.exe program can catch errors when the program is running)
that programme language is good because the programmer is free to
think on the routine (and not make much attention on some class of
error that are easy catch from the program itself)
it is easier to do errors in a function that allow to do 50 type of
errors than the one routine that has only 1 possibility to do one
error.
\~o/~///annabee
i'm not agree; if a language can minimize errors (for example if the
.exe program can catch errors when the program is running) that
programme language is good because the programmer is free to think on
the routine (and not make much attention on some class of error that
are easy catch from the program itself)
it is easier to do errors in a function that allow to do 50 type of
errors than the one routine that has only 1 possibility to do one
error.//
In 'a function' there is simply never (in reality) a possibility of 50
errors. Espesially not in asm.
Anyway, can you name such a language that catches the programmers
errors? And what kind of errors does it catch?
Betov
4ax.com:
> i'm not agree; if a language can minimize errors (for example if the
> .exe program can catch errors when the program is running)
> that programme language is good because...
This is not the job of the _language_ to take any
decision on the errors management.
> the programmer is free to
> think on the routine (and not make much attention on some class of
> error that are easy catch from the program itself)
:)
We all know how the Languages that make "the programmer
free from thinking" end up.
:)
> it is easier to do errors in a function that allow to do 50 type of
> errors than the one routine that has only 1 possibility to do one
> error.
I suppose you do mean something, but dispiting my own
awfull english, i don't understand a word of this
sentence.
:))
The bugs _must_ happend, before being detected, and
_must_ be detected, before being fixed.
Implementing securities, is most often "hyding" the
bugs, than doing any good. The only valid rule, in that
matter, is to have the error signals coming as sooner
as possible: "Write-Time Error Messages" first. The
very best. "Compile-Time Error Messages", second, and
"Run-Time Error Messages", last, but as violent as possible,
to _require_ an immediate fix.
Another problem to consider is with the accuracy of the
Errors Messages, that comes with the exact same logic.
That is, Specific Errors Messages, implemented _when
required_, instead of systematic ones, are WAY better.
:)
Betov.
Rod Pemberton
"\~o/~///annabee" <f...@szmyggenpv.com> wrote in message
news:1140327113.2...@g14g2000cwa.googlegroups.com...
Pointers in Pascal are very limited compared to pointers in PL/1 or C. They
are restricted or type safe. IIRC, Niklaus Wirth made them explicitly bound
to the datatype which isn't true in PL/1 or C, and they can't be assigned an
absolute memory address. Also, IIRC, one can't do pointer arithmetic in
Pascal. Basically, pointers in Pascal are safe, limited, useless, and
Dragontamer
Java catches memory out of bounds errors automatically for example.
This includes off by one errors in arrays also.
This prevents buffer overflows and nasty stuff of that nature.
There was an error in C that was corrected in Java (and to some effect,
this error can happen in assembly language as well)
This was the good old c = getChar error, where they wanted to test
if c == getChar, not c set equal to getChar. Java corrected this by
only
allowing booleans in if and while statements.
In Lisp, Python, etc. it is impossible to have an overflow error.
In C#, supposedly it automatically catches overflow and underflow.
In any typed HLL, just the design prevents you from entering the wrong
kind
of data as a parameter. (C, C++, etc. etc.)
--Dragontamer
柑\/b
<f...@szmyggenpv.com> wrote:
>//
>i'm not agree; if a language can minimize errors (for example if the
>.exe program can catch errors when the program is running) that
>programme language is good because the programmer is free to think on
>the routine (and not make much attention on some class of error that
>are easy catch from the program itself)
>
>it is easier to do errors in a function that allow to do 50 type of
>errors than the one routine that has only 1 possibility to do one
>error.//
>
>In 'a function' there is simply never (in reality) a possibility of 50
>errors. Espesially not in asm.
you can see the C library function fgets; only now seems i know how
this function could be ok
iamfr...@hotmail.com
Evenbit wrote:
> How would you go about designing an Ideal computer language from
> scratch?
I was going to write that you should consider what applications you
want to write in your NewLanguage. You'll be dealing in fundamentals,
so you'll inevitably face the power/productivity trade-off: asm is the
most powerful language there is, but you wouldn't want to write a word
processor in it; Java would make a terrible language for an operating
system (though I've heard there is such a beast), but it's fine for a
GUI.
I was going to write that, but I didn't. :)
If I were you, I'd start way, way off-base, and only spiral in towards
accepted norms when you have clarified your reasons for doing so. If
nothing else, it'll be interesting research.
For example, someone here mentioned that consistency is important, and
it undoubtedly is, but you shouldn't take it on face value. Consider,
for example, a language that allowed totally different syntax rules in
different parts. These different parts only had to conform to a common
syntax subset where they interfaced with one another. Consider, too,
that some of these parts could have user-defined syntax.
I'm not for a moment saying that this would be a Good Thing: I'm saying
that you should examine it and clarify why it's a Bad Thing.
Choose loads of bizarre stuff like this.
For example: perhaps the biggest problem with software is that it can,
"Go wrong;" i.e., it can do something that you told it to do (e.g.,
buffer overrun) but that you didn't realise that you had told it to do.
Dream up a language that cannot go wrong. (Simple.) Or if that can't be
done, then how about a language which lets the user open an interactive
shell with the source code itself, so that the user can talk to the
code before it's even run. Maybe the source code would be able to spot
potential problems better than the programmer.
How about a language with no conditional operators?
How about a language with no commands whatsoever?
How about a non-linear langauge?
How about a language that used, not by starting with an empty file for
the programmer to being filling up, but by starting with a full
application, and the language's syntax is simply a predefined series of
refactorings?
How about a language whose syntax is a debate with the compiler, so
that, for every line the programmer writes, the compiler adds something
itself, which the programmer must then change to his desire?
How about a language that exists only at compile-time and never
exhibits run-time behaviour?
How about a language whose programs run at write-time?
How about a language with a read-only syntax whose behaviour is based
on statically combining behaviours to achieve an overall effect?
How about a language whose syntax is three-dimensional?
.ed
--
www.EdmundKirwan.com - Home of The Fractal Class Composition.
Betov
@f14g2000cwb.googlegroups.com:
> you'll inevitably face the power/productivity trade-off: asm is the
> most powerful language there is, but you wouldn't want to write a word
> processor in it
As this sentence demonstrates that you know nothing
about Assembly, how could your opinion have any base?
Betov.
iamfr...@hotmail.com
Betov skrev:
Hi, Betov,
I do apologise if I caused offence; of course, some people consider asm
the perfect language for word processing applications.
The OP is perfectly entitled to disregard my opinion.
Dragontamer
iamfr...@hotmail.com wrote:
> Choose loads of bizarre stuff like this.
Kinda funny, I've seen some languages like you describe...
[snip those I can't find an example of]
> How about a non-linear langauge?
Haskell is not run from "beginning to end" at all. The language doesn't
guarentee an order of operations aside from basic mathematical
computations.
The idea here is that a mathematical function is not "procedural", but
instead,
entirely defined by mathematical operations. If x and y are functions,
with
x + y, you shouldn't care whether x or y is executed first; in fact,
Haskell
can theoretically create a thread for both and then execute them
simultaniously.
The language is interesting because it has no "side-effects" in the
basic language,
and you can only have side-effects by using a small-subset of the
language.
I suggest looking into it just as an exersize.
> How about a language that exists only at compile-time and never
> exhibits run-time behaviour?
M4 macro language. :-p
> How about a language whose programs run at write-time?
Again, macros. Lisp and Scheme have a massive blur between
"compile-time" and "run-time", with programs that exist only during
compile time and so forth.
--Dragontamer
rand...@earthlink.net
iamfr...@hotmail.com wrote:
> Evenbit wrote:
>
> > How would you go about designing an Ideal computer language from
> > scratch?
>
> I was going to write that you should consider what applications you
> want to write in your NewLanguage. You'll be dealing in fundamentals,
> so you'll inevitably face the power/productivity trade-off: asm is the
> most powerful language there is, but you wouldn't want to write a word
> processor in it;
Actually, word processors are among the apps for which assembly is
reasonably suited.
> Java would make a terrible language for an operating
> system (though I've heard there is such a beast), but it's fine for a
> GUI.
Why would Java (assuming compiled, of course) be any worse than C++? If
Unix & C proved that we didn't have to write OSes in assembly language,
where do we draw the line? Why not write an OS in Perl? :-)
> If I were you, I'd start way, way off-base, and only spiral in towards
> accepted norms when you have clarified your reasons for doing so. If
> nothing else, it'll be interesting research.
Most new languages created these days really are nothing more than
"interesting research". The really sad thing is that no one has taken
all the interesting ideas from "research" languages and combined them
into a practical general-purpose language over the past 20 years or so.
>
> For example, someone here mentioned that consistency is important, and
> it undoubtedly is, but you shouldn't take it on face value. Consider,
> for example, a language that allowed totally different syntax rules in
> different parts.
You mean, like Perl?
> These different parts only had to conform to a common
> syntax subset where they interfaced with one another. Consider, too,
> that some of these parts could have user-defined syntax.
I happen to believe that the ability to have user-defined syntax (that
is, a butt-kicking macro system) is a good thing. Apparently, I am in
the minority. Languages like this have existed in the past. The
user-defined syntax thing was abused and people came away thinking that
user-defined sytax is "a bad thing" (tm).
As for the jumble of syntax you propose with the first sentence here,
too many languages (e.g., Perl) have this already. They are hard to
learn and, despite the claims of the few who know every nook and cranny
of the language, they are hard to use. Try writing a wide variety of
Perl applications without having the manual handy, for example. Try
reading a Perl program written by someone who uses a completely
different programming style.
>
> I'm not for a moment saying that this would be a Good Thing: I'm saying
> that you should examine it and clarify why it's a Bad Thing.
If you have a language that offers a large variety of ways to
accomplish one thing, just for the sake of variety, the programs will
be unreadable by a large variety of people. This is a well-understood
concept in programming languages.
OTOH, if you have a very simple language that forces people to do
things all the same way, you gain readability at the expense of
expressibility. And the ultimate result is that programs are generally
larger, take longer to develop, and (believe it or not) have more bugs.
(I am talking about the first version of the code here, ultimately,
software engineering principles win out when lots of hands need to
touch the code.)
>
> Choose loads of bizarre stuff like this.
>
> For example: perhaps the biggest problem with software is that it can,
> "Go wrong;" i.e., it can do something that you told it to do (e.g.,
> buffer overrun) but that you didn't realise that you had told it to do.
> Dream up a language that cannot go wrong. (Simple.)
Those who think they can devise an "idiot-proof language" completely
underestimate the talent of all the idiots in the world :-)
> Or if that can't be
> done, then how about a language which lets the user open an interactive
> shell with the source code itself, so that the user can talk to the
> code before it's even run.
IOW, write an interpreter.
> Maybe the source code would be able to spot
> potential problems better than the programmer.
Strong type checking, semantic checking, there are common things in
modern languages.
BTW, ever use PL/C? It was a kick to see it correct obvious syntax
errors in program and come up with comments like "PL/C uses...." Of
course, it was also funny to see it screw up royally and turn a
syntactically incorrect statement into one that was syntactically
correct, but semantically way off the mark.
>
> How about a language with no conditional operators?
See MMX and SSE.
>
> How about a language with no commands whatsoever?
What's a command?
>
> How about a non-linear langauge?
AKA "declarative languages". See Prolog, Flex, Bison, etc., for
examples.
>
> How about a language that used, not by starting with an empty file for
> the programmer to being filling up, but by starting with a full
> application, and the language's syntax is simply a predefined series of
> refactorings?
Who writes the "full application" in the first place?
>
> How about a language whose syntax is a debate with the compiler, so
> that, for every line the programmer writes, the compiler adds something
> itself, which the programmer must then change to his desire?
Sounds like one of the code obfuscator programs :-)
>
> How about a language that exists only at compile-time and never
> exhibits run-time behaviour?
Macros.
>
> How about a language whose programs run at write-time?
Many editors contain built-in programming languages to do text
expansions and the like. This would be a good example of such a
language.
>
> How about a language with a read-only syntax whose behaviour is based
> on statically combining behaviours to achieve an overall effect?
How do you "statically combine" behaviors if it is read-only?
>
> How about a language whose syntax is three-dimensional?
What do you mean by three-dimensional? If you're talking about page
layout, most languages today are only one-dimensional. If you're
talking about independent variables, most language's syntax is already
multi-dimensional (well beyond three dimensions).
There are many reasons for creating a new language. Lately, the main
reason has been simply to prove a certain point (generally, these are
research languages). For practical languages, a new language should
have several salient features:
1) It should be easy to learn (and should employ the concept of
"restrictability", which means that a programmer can learn a subset of
the language and write meaningful programs with just that subset).
2) It should be easy to use once someone learns it.
3) The language should translate to an exectuable module that makes
efficient use of machine resources (e.g., speed and space being two of
those resources).
4) It should be extensible (user or otherwise).
5) It should encourage good software engineering principles, but allow
programmers to do whatever they wish with it.
6) It should combine the good features of older languages and dispense
with the bad features of those languages. It should maintain a
familiarity with old languages (to protect case (1)) but it shouldn't
carry around any "old baggage" for the sake of compatibility.
There are lots of good attributes a new programming language should
possess. I'd recommend picking up a decent textbook on programming
language design (there are many) and reading about the subject. It is
fascinating.
Cheers,
Randy Hyde
Betov
news:1140542356.0...@o13g2000cwo.googlegroups.com:
> Those who think they can devise an "idiot-proof language" completely
> underestimate the talent of all the idiots in the world :-)
On this point, you must be a real expert, aren't you,
ass-hole?
:)
Betov.
Betov
news:1140542356.0...@o13g2000cwo.googlegroups.com:
> Sounds like one of the code obfuscator programs :-)
HLA?
:)
Betov.
\~o/~///annabee
all the interesting ideas from "research" languages and combined them
into a practical general-purpose language over the past 20 years or
Yes René Tournois did this with his Rosasm.
//I happen to believe that the ability to have user-defined syntax
(that
is, a butt-kicking macro system) is a good thing. Apparently, I am in
the minority
Cheers Randall Hyde//
This is what RosAsm is, a dream tool for creating a custom syntax. Even
many diffrent once inside each application.
[snip....too long..... post.....]
Dragontamer
\~o/~///annabee wrote:
> // The really sad thing is that no one has taken
> all the interesting ideas from "research" languages and combined them
> into a practical general-purpose language over the past 20 years or
> so.//
>
> Yes René Tournois did this with his Rosasm.
I thought Rene didn't use HLLs?
--Dragontamer
JGCASEY
rand...@earthlink.net wrote:
> For practical languages, a new language should
> have several salient features:
>
> 1) It should be easy to learn (and should employ
> the concept of "restrictability", which means that
> a programmer can learn a subset of the language
> and write meaningful programs with just that subset).
>
> 2) It should be easy to use once someone learns it.
>
> 3) The language should translate to an exectuable
> module that makes efficient use of machine resources
> (e.g., speed and space being two of those resources).
>
> 4) It should be extensible (user or otherwise).
>
> 5) It should encourage good software engineering
> principles, but allow programmers to do whatever they
> wish with it.
>
> 6) It should combine the good features of older
> languages and dispense with the bad features of those
> languages. It should maintain a familiarity with old
> languages (to protect case (1)) but it shouldn't carry
> around any "old baggage" for the sake of compatibility.
Windows lacks a language with *all* the above.
A useful new language would be one that gives power to
the part time programmer without losing the above need
for efficient use of machine resources, in particular
speed which is the failure of all HLLs. This includes
VC++ *and* Assembler which is as slow as QBasic thanks
to the Windoze OS. Sure there are complex hard to
learn ways around it but this is, as you state above
(see requirement 2), exactly what makes these languages
VC++ and Assembler crap when it comes to giving a part
time programmer access to the PC resources.
--
JC
\~o/~///annabee
--Dragontamer
He dont. And I was a bit fast, because it would better say : that Renè
has taken the best ideas, from whatever language and removed the many
stupid ideas from the "research" over the past 20 years.
:) Its funny to me, because, I am for once in my life the one that
really see what a bunch of educated assholes will never be able to see.
Its both thrilling and confusing. I am not sure if I want you to see,
what an incredible gift RosAsm is, or if I want to kill you. (Randall
Hyde I mean).
Dragontamer
How do you know it has never been seen if you don't use those
experimental languages? How do you know RosAsm has all the
best stuff from all those languages?
Just a few languages that have *great* ideas (or at least gets an A for
creativity)
Haskell : A language where you don't have to worry about side-effects.
You talk of languages that "hide", Haskell cannot, as it has elimiated
everything
hidden.
Lisp/Scheme: Fractions as a data-type.
Why for the love of (insert anything here) does no language support
rational numbers?
Lisp/Scheme stores 1/3 as exactly, 1 / 3.
Bash/Korn/sh/tsh, etc. etc.: Totally integrated with the Operating
system. Any program
created for the OS automatically becomes a function to this programming
language.
I could go on... but I know you haven't tried Haskell or Scheme/Lisp
yet :-p
--Dragontamer
sevagK
> Haskell : A language where you don't have to worry about side-effects.
>
> You talk of languages that "hide", Haskell cannot, as it has elimiated
> everything
> hidden.
>
I took a look at this today (WinHugs). It reminds me too much of FORTH
with a different notation. I don't much like FORTH. At least it makes
a good calculator.
-sevag.k -=Kain=-
www.geocities.com/kahlinor
Chew...@austarnet.com.au
Evenbit wrote:
> For the last few days, I've been pondering the simularities between
> different languages and some of the things I like and dislike about
> these languages.
Also for some exotic languages check out:
http://b.webring.com/hub?ring=esolang
PS. Both NULL and COW look interesting...
Dragontamer
Cow just looks like yet another copycat of Brainfuck :-/
--Dragontamer
Chew...@austarnet.com.au
> I thought Rene didn't use HLLs?
> --Dragontamer
>
> He dont. And I was a bit fast, because it would better say : that Renè
> has taken the best ideas, from whatever language and removed the many
> stupid ideas from the "research" over the past 20 years.
Like what?
I would have thought that object code generation that can be linked to
other object code to be one of the good ideas in Computer Science?
> :) Its funny to me, because, I am for once in my life the one that
> really see what a bunch of educated assholes will never be able to see.
> Its both thrilling and confusing. I am not sure if I want you to see,
> what an incredible gift RosAsm is, or if I want to kill you. (Randall
> Hyde I mean).
I'm sorry to be the bearer of bad news, but I personally don't believe
RosAsm to be an 'incredible' gift, and I'm sure the majority of both
professional and hobby programmers would be of the same opinion... Yes,
RosAsm does have a place within the asm community, but to classify it
as an incredible gift, I don't think so... (It simply lacks many of the
things I look for in an assembler, and if it's missing stuff that a
hobby programmer is looking for, what opinion would a professional
hold).
Chew...@austarnet.com.au
Dragontamer wrote:
Well, it's along the same lines...
The question I would like to pose, could langauages like BF and COW be
considered assembly languages? (abielt for a fictional CPU).
Dragontamer
I'd say yes; because Lisp and Scheme are considered "assembly language"
for
fictional Lisp and Scheme computers. :-) (at least by Lisp supporters
and stuff)
--Dragontamer
Charles A. Crayne
Chew...@austarnet.com.au wrote:
:(It simply lacks many of the
:things I look for in an assembler, and if it's missing stuff that a
:hobby programmer is looking for, what opinion would a professional
:hold)
I don't see that much of a dichotomy between professional and hobby
programmers, given that so many of us have one foot in each camp, but I
can tell you opinion they would hold, "I don't want to use it, because it
doesn't look like what I am familiar with".
-- Chuck
Charles A. Crayne
Chew...@austarnet.com.au wrote:
:The question I would like to pose, could langauages like BF and COW be
:considered assembly languages? (abielt for a fictional CPU).
Yes, of course. I have it on good authority that there was once an
experimental cpu that ran ALGOL as its machine language.
-- Chuck
Chew...@austarnet.com.au
Charles A. Crayne wrote:
> On 21 Feb 2006 18:44:43 -0800
>
> :The question I would like to pose, could langauages like BF and COW be
> :considered assembly languages? (abielt for a fictional CPU).
>
> Yes, of course. I have it on good authority that there was once an
> experimental cpu that ran ALGOL as its machine language.
Hi Chuck,
Impressive, I knew that a few FORTH based CPUs were made, as well as
CPUs that can operate natively on java bytecode, but ALGOL is quite
impressive...
\~o/~///annabee
> stupid ideas from the "research" over the past 20 years.
//
Like what?
//
I have explained this, in 1000s of posts in this ng, over and over. The
regulars are pretty sick of it, and I have to agree with them. But In
short :
What took me 5 years todo in HLL, took me 2 years todo _better_ in asm.
Only the result in asm has far less errors, and runs very much faster.
What is now the bottleneck, is the OS! This was not true for the HLL
version.
Enough said ?
This was my little experiment. And the results pratically proves that
HLLS are much worse tools for doing this kind of programming. (Any)
I will upload again, the HLL version of the program, along with the asm
version, for comparison, a little bit later on, in a page explaining
the diffrences.
Both the HLL version of the app, and the asm version are close to
IDENTICAL in operation, except the asm version has more user options,
has much fewer bugs, and runs instant in most of the cases.
The codebase for both applications are _FULLY_ reusable. But theres
much more possibilities in the asm version.
//I'm sorry to be the bearer of bad news, but I personally don't
believe RosAsm to be an 'incredible' gift, and I'm sure the majority of
both
professional and hobby programmers would be of the same opinion...//
This is why I am thrilled. I cant be sad for you, I just shake my head
and feel friendly pity for the lot of you. :)))) :)))
// Yes,
RosAsm does have a place within the asm community, but to classify it
as an incredible gift, I don't think so..//
RosAsm is to computer languages what the computer once wore to sending
messages via (snailmail). Its a paradigm shift. RosAsm will flurish
like the new tool on the block, once the programmers all have moved to
64bit machines, and finally starts seeing that there are no free
lunches in programming.
The HLL written apps I have, runs sometimes WORSE on my 64bit AMD 3700,
then on my 1000mhz AMD athlon XP. So, to run Windows on this new
machine is the same bloddy fuckup, swearing involved, terrible and
strange wait states, lockups, and a slow degradation of the speed of
the OS. I use the win32 OS, and have not tested the 64bit version yet.
This will lead them to understand that what you do not pay now, you pay
later, and this will then turn them to assembly. When that dession is
made, theres only one serious choise.
Compared to RosAsm, the other assemblers AND HLLs are weaklings.
\~o/~///annabee
yet :-p
--Dragontamer //
No, I havent, because I use asm, and so, whatever I need in my code, I
can create. The point of asm to me is not about being unproductive, at
all. I first write UP the basic functionality I need for my target
application, and then I use this spesific code to do more involving
task.
Bertrand Augereau
Wow.
\~o/~///annabee
>Wow.
Yeah!!!! :)))
Alex McDonald
The machine you're referring to was possibly a Burroughs B5000 series;
the operating system was written in ESPOL (an ALGOL variant), and the
underlying machine instruction set was specifically designed to support
it. It was far from experimental. See
http://en.wikipedia.org/wiki/ESPOL and Google search on "burroughs
b5500".
--
Regards
Alex McoDonald
Chew...@austarnet.com.au
> > He dont. And I was a bit fast, because it would better say : that Renè
> > has taken the best ideas, from whatever language and removed the many
> > stupid ideas from the "research" over the past 20 years.
>
> //
> Like what?
> //
>
> I have explained this, in 1000s of posts in this ng, over and over. The
> regulars are pretty sick of it, and I have to agree with them. But In
> short :
>
> What took me 5 years todo in HLL, took me 2 years todo _better_ in asm.
> Only the result in asm has far less errors, and runs very much faster.
> What is now the bottleneck, is the OS! This was not true for the HLL
> version.
>
> Enough said ?
But wouldn't that be a result of learning and using assembly, rather
than a specific tool? I'm sure you could say the same if you used HLA,
MASM32, FASM, or even NASM.
> This was my little experiment. And the results pratically proves that
> HLLS are much worse tools for doing this kind of programming. (Any)
>
> I will upload again, the HLL version of the program, along with the asm
> version, for comparison, a little bit later on, in a page explaining
> the diffrences.
>
> Both the HLL version of the app, and the asm version are close to
> IDENTICAL in operation, except the asm version has more user options,
> has much fewer bugs, and runs instant in most of the cases.
>
> The codebase for both applications are _FULLY_ reusable. But theres
> much more possibilities in the asm version.
The thing is Wannabee, you still have not answered the question I
posed, "What ideas has Rene used and not used in creating RosAsm based
on research of the past 20 years?"
Some of them, I would say:
1. Object file creation for linking at a later time (Rene doesn't have
this, yet just about every Assembler/HLL toolchain has this ability,
and is considered to be 'a good thing' in computer science.) I would
place this around, what 1960's based research?
2. Multiply source files. How do many programmers work on the same
project, if the entire project is in 1 source file?
3. The internal hashing algorithm doesn't cleanly allow for collisions.
As a programmer, I would refuse to use a tool that would fail to 2
separate tokens (or keywords) hashed to the same value, and the tool
wouldn't differentiate between them simply becuase the hash is the
same...
Does Rene provide a clean runtime scripting langauge within the
assembler? Advanced macro facilities.
Does Rene provide a clean OOP framework or macro facilities which can
help in OOP.
Does Rene provide support for clean integration with other langauges?
Does Rene support other debuggers and their file formats? eg DWARF.
Does RosAsm perform jump size optimisations to the same level as other
common assemblers? eg MASM, FASM, NASM?
Does Rene support x86-64 or Itanium or Alpha or PPC or MIPS? (He claims
it's a Windows/ReactOS specific assembler which I have no problem with,
but Windows is available on x86, x86-64 (aka x64), Itanium, Alpha, PPC,
MIPS, so why doesn't RosAsm support those architectures as well)?
Does Rene provide clean support for a SQL based RDBS. What about
writing CGI's for IIS.
Does RosAsm provide support for project files and integration into SCM
systems. (Source Code Management, eg CVS, Subversion, Visual Source
Safe, etc).
Actually Wannabee, can you even name 5 of the top research fields in
language/compiler design of the last 20 years?
> //I'm sorry to be the bearer of bad news, but I personally don't
> believe RosAsm to be an 'incredible' gift, and I'm sure the majority of
> both
> professional and hobby programmers would be of the same opinion...//
>
> This is why I am thrilled. I cant be sad for you, I just shake my head
> and feel friendly pity for the lot of you. :)))) :)))
Well, please enlighten me. What features do you believe RosAsm has that
I currently don't access to, using my current toolchain? (FASM, gdb,
jEdit, Soft-Ice).
> // Yes,
> RosAsm does have a place within the asm community, but to classify it
> as an incredible gift, I don't think so..//
>
> RosAsm is to computer languages what the computer once wore to sending
> messages via (snailmail). Its a paradigm shift. RosAsm will flurish
> like the new tool on the block, once the programmers all have moved to
> 64bit machines, and finally starts seeing that there are no free
> lunches in programming.
Since when did RosAsm support x86-64 64bit code generation? IIRC, only
MASM, gas, FASM and YASM supported x86-64 64bit code generation.
> The HLL written apps I have, runs sometimes WORSE on my 64bit AMD 3700,
> then on my 1000mhz AMD athlon XP. So, to run Windows on this new
> machine is the same bloddy fuckup, swearing involved, terrible and
> strange wait states, lockups, and a slow degradation of the speed of
> the OS. I use the win32 OS, and have not tested the 64bit version yet.
That's strange, I don't have any of those issues with either running
WinXP-x64 or Linux (AMD64) on my dual-Opteron box. Maybe you just
bought cheap crap or haven't installed Windows correctly... (Only a bad
workman blames his tools).
> This will lead them to understand that what you do not pay now, you pay
> later, and this will then turn them to assembly. When that dession is
> made, theres only one serious choise.
If the bottleneck as you say is the OS, how is moving to assembly going
to help?
> Compared to RosAsm, the other assemblers AND HLLs are weaklings.
See above...
Dragontamer
So how do you claim that Assembly is the best when you have
not tried these languages to compare?
--Dragontamer
Dragontamer
\~o/~///annabee wrote:
> > He dont. And I was a bit fast, because it would better say : that Renè > has taken the best ideas, from whatever language and removed the many
> > stupid ideas from the "research" over the past 20 years.
>
> //
> Like what?
> //
>
> I have explained this, in 1000s of posts in this ng, over and over. The
> regulars are pretty sick of it, and I have to agree with them. But In
> short :
>
> What took me 5 years todo in HLL, took me 2 years todo _better_ in asm.
> Only the result in asm has far less errors, and runs very much faster.
> What is now the bottleneck, is the OS! This was not true for the HLL
> version.
>
> Enough said ?
What HLLs did you compare? I highly doubt you didn't compare _all_
HLLs,
and each one is different in its own respect (why, I'd have to say
HLLs are _more_ different than the differences between assembly
languages)
And I hate to jump the boat and assume you've only tried Delphi. But
seriously,
C, C++, Delphi... all three (which you were likely to try) are at least
20 years old.
And IIRC, you haven't tried any other HLL other than those 3.
C being invented in the 70s, C++ having roots in the 80s, and Delphi
has roots
with Pascal. In fact, I'd doubt any of these languages can even claim
to have
taken stuff in from the "past 20 years" when the languages are older
than 20 years...
Why, x86 assembly is technically "younger" than C. Hardly a good
comparison
if you ask me.
Where are your experiances with Python, OCaml, Haskell,
Java, ObjC, Prolog, Forth?
===========
Second: the only thing your experiment proves is that you are
incompetent with HLLs, and competent with assembly.
--Dragontamer
\~o/~///annabee
not tried these languages to compare?
Assembly is the native language of the computer.
I use asm for the same reason I use English when I want to be
understood by people who dont speak my native tongue. To be better
understood.
If I "talk" to the CPU in some language foreign to it, it may not
allways do exactly what I was indending to tell it. It will sometimes
misinterpret my communcation.
In asm, you get what you think, so when something is wrong its with
once thinking, and not with the language.
Anyway, I think the question was stupid, and this is the best I could
do to rectify a silly question.
\~o/~///annabee
HLLs,//
You starting to sound more and more like the swindler. This is the most
incredible stupid question / suggestion ever.
[snip rest unread]
Dragontamer
Silly question? I'm asking where do you have the basis to compare
HLLs (most of which you've never used I'm sure) to Assembly language?
Yes, we know you are at least competent with Assembly; but if you
aren't good with HLLs, then where is your basis for saying HLLs are
worse than RosAsm?
--Dragontamer
rand...@earthlink.net
IOW, he's asking questions for which you have no answer because you've
shot off your mouth in ignorance. So you have to resort to name calling
rather than coming back with an intelligent reply.
Cheers,
Randy Hyde
Dragontamer
Chew...@austarnet.com.au wrote:
> The thing is Wannabee, you still have not answered the question I
> posed, "What ideas has Rene used and not used in creating RosAsm based
> on research of the past 20 years?"
>
> Some of them, I would say:
> 1. Object file creation for linking at a later time (Rene doesn't have
> this, yet just about every Assembler/HLL toolchain has this ability,
> and is considered to be 'a good thing' in computer science.) I would
> place this around, what 1960's based research?
> 2. Multiply source files. How do many programmers work on the same
> project, if the entire project is in 1 source file?
> 3. The internal hashing algorithm doesn't cleanly allow for collisions.
> As a programmer, I would refuse to use a tool that would fail to 2
> separate tokens (or keywords) hashed to the same value, and the tool
> wouldn't differentiate between them simply becuase the hash is the
> same...
May I add to the list?
4. Impervious to Buffer Overflow bugs. (Java for example)
5. Regex file searcher. (i use grep, supposedly VC++ has it, but I
don't use it)
6. Integrated mutex support ("synchronize" keyword in Java)
7. Portable runtime-GUI (Java... again... Funny, I hate Java but it has
so many good
ideas. Fine fine, I'll use ObjC/GnuStep's Renaissance found:
http://www.gnustep.it/Renaissance/ along with ObjC/GnuStep's GORM)
8. Regex embedded to the language. (Perl, Ruby) or standard RegEx
support
of some kind (Java, POSIX / C)
9. Ability to restrict aliasing problems (C99, restrict keyword to
prevent
unwanted aliasing of pointers)
10. GUI designers
11. Integration into different languages
12. Exception handling (C++, Java)
13. Complete lack of compile->run cycle (most interpreters; especially
Emacs/Lisp)
14. Source Version Control (CVS, RCS, etc. etc.)
Well, some of these are older than 20 years old (wow, 20 years ago was
1986...) such
as grep, and ideas to prevent Buffer Overflow and lack of compile-run
cycle...
But I like those ideas :) I'm sure I'm missing quite a few big ones.
--Dragontamer
Dragontamer
Seriously, just answer this question:
What HLLs have you used in your "5 years of HLLs" experiance?
If it was not all; then you obviously cannot compare "all HLLs" to
assembly,
as you have not used all.
--Dragontamer
rand...@earthlink.net
Dragontamer wrote:
>
> May I add to the list?
>
> 4. Impervious to Buffer Overflow bugs. (Java for example)
Pascal and Basic had these, over 20 years ago.
> 5. Regex file searcher. (i use grep, supposedly VC++ has it, but I
> don't use it)
SNOBOL4 and Icon had these, over 20 years ago.
> 6. Integrated mutex support ("synchronize" keyword in Java)
Modula-2 had these, over 20 years ago.
> 7. Portable runtime-GUI (Java... again... Funny, I hate Java but it has
> so many good
> ideas. Fine fine, I'll use ObjC/GnuStep's Renaissance found:
> http://www.gnustep.it/Renaissance/ along with ObjC/GnuStep's GORM)
The concept of portable GUIs didn't exist, to my knowledge, 20 years
ago, so this is a new one.
> 8. Regex embedded to the language. (Perl, Ruby) or standard RegEx
> support
> of some kind (Java, POSIX / C)
Snobol and Icon had these over 20 years ago.
> 9. Ability to restrict aliasing problems (C99, restrict keyword to
> prevent
> unwanted aliasing of pointers)
Pascal had these, over 20 years ago.
> 10. GUI designers
Smalltalk had these, over 20 years ago.
> 11. Integration into different languages
Hmmm, just about every compiled language had these?
> 12. Exception handling (C++, Java)
PL/I had this over 20 years ago.
> 13. Complete lack of compile->run cycle (most interpreters; especially
> Emacs/Lisp)
LISP had this, way over 20 years ago.
> 14. Source Version Control (CVS, RCS, etc. etc.)
This isn't really a language feature. But source code control came out
of the 70s, at latest.
>
> Well, some of these are older than 20 years old (wow, 20 years ago was
> 1986...) such
> as grep, and ideas to prevent Buffer Overflow and lack of compile-run
> cycle...
Yep. Portable GUI is the only idea I *think* is newer than 20 years
old.
(And RosAsm, of course, isn't portable, so that doesn't apply here.)
>
> But I like those ideas :) I'm sure I'm missing quite a few big ones.
Garbage collection and automatic memory management.
Dynamic typing systems.
Goal-directed execution.
Just to name a few.
Cheers,
Randy Hyde
rand...@earthlink.net
Actually, he claims to have had 10 year's of Delphi experience (and
this claim was made several years ago when Delphi was barely 10 years
old). And after all that experience, he still hadn't figured out how to
do a linked list in Delphi. Look up the post where he bragged about how
easy it was to do linked lists in RosAsm and he had been unable to do
that in Delphi. You'd think after 10 years of using Delphi (and
apparently Turbo Pascal before that, according to some recent posts) he
would have figured out how to do linked lists in Pascal.
Cheers,
Randy Hyde
rand...@earthlink.net
The same way Rene claims that RosAsm is the fastest of all actual
assemblers when he hasn't bothered to compare its speed against any of
the assemblers. Wannabee has "learned from the master" :-).
Cheers,
Randy Hyde
Dragontamer
rand...@earthlink.net wrote:
> Dragontamer wrote:
[snip]
> > Well, some of these are older than 20 years old (wow, 20 years ago was
> > 1986...) such
> > as grep, and ideas to prevent Buffer Overflow and lack of compile-run
> > cycle...
>
> Yep. Portable GUI is the only idea I *think* is newer than 20 years
> old.
> (And RosAsm, of course, isn't portable, so that doesn't apply here.)
> >
> > But I like those ideas :) I'm sure I'm missing quite a few big ones.
>
> Garbage collection and automatic memory management.
> Dynamic typing systems.
> Goal-directed execution.
> Just to name a few
Lisp had Garbage Collection and auto-mem management back in the 60s :-p
Grr... I forgot one of my favorites:
Continuations!!!
http://en.wikipedia.org/wiki/Continuation#Programming_language_support
Basically, you rebuild the stack-frame and then jump to the function.
-----
Other stuff as well:
Built-in coRoutines (Lua)
By built-in, I don't mean how we do it in assembly. In Lua, you can
combine
2 functions and turn them into coRoutines rather easily. It even has a
little
"coroutine.yeild" function that switches over to the other coroutine
instantly.
---
Extreme Lazyness (haskell)
fibo = 1 : 1 : zipWith (+) fibo (tail fibo)
Creates a list called "fibo" that can be passed around like a normal
datatype,
and it generates the fibinocci sequence as needed. Aka, extreme
lazyness.
Whether it is a good or bad thing :-p But it is still a nice idea.
---
I heard of this "aspect oriented" programming somewhere, along with
"logic" programming in prolog. I dunno much about them, but I'll just
toss
them in.
--Dragontamer
Dragontamer
rand...@earthlink.net wrote:
> Dragontamer wrote:
> > \~o/~///annabee wrote:
> > > //What HLLs did you compare? I highly doubt you didn't compare _all_
> > > HLLs,//
> > >
> > > You starting to sound more and more like the swindler. This is the most
> > > incredible stupid question / suggestion ever.
> > >
> > > [snip rest unread]
> >
> > Seriously, just answer this question:
> >
> > What HLLs have you used in your "5 years of HLLs" experiance?
> >
> > If it was not all; then you obviously cannot compare "all HLLs" to
> > assembly,
> > as you have not used all.
> >
> > --Dragontamer
>
> Actually, he claims to have had 10 year's of Delphi experience
Ah, my mistake then.
So back to the original question :)
What languages have you used in your 10+ years of HLL experiance?
--Dragontamer
Chew...@austarnet.com.au
> rand...@earthlink.net wrote:
> >
> > Actually, he claims to have had 10 year's of Delphi experience
>
> Ah, my mistake then.
>
> So back to the original question :)
>
> What languages have you used in your 10+ years of HLL experiance?
Well here is my list:
CBM Basic (Commodore 64), GW Basic, QBasic, and few other BASICs from
the 8bit era.
Turbo Pascal, DEC Pascal (on OpenVMS), FreePascal.
Turbo C, Turbo C++, GCC, VC++.
PHP & Python & Javascript.
VBScript and BASH scripting.
And played with: Delphi, FORTH, Haskell, LISP, LOGO and Hypercard
(MacOS).
Not including hobby or exotic langauges like b0 (my own language),
BrainF**k, and various assembly languages: x86, x86-64, 68K, 6502/6510
and some PPC (G3 on an iMac), MIPS (Playstation) and StrongARM (iPAQ
PDA).
But my list certainly is not impressive as some of the others here...
PS. @Wannabee: still waiting on a response to my post?
Dave
1100/60 series based upon the old 1108 have a real language that the
machine uses, but the 'assembler' used is the old 1108 version that is
really micro-ops in the new processors.
It is more difficult to write assembly than to use a HLL. If I write
something in 'C', C++, Python, Fortran, or even Cobol that works to
accomplish the needed task, how is this even possible of
misunderstanding? A compiler, including even assemblers have to
format the source code into machine code. Just a relative jump to a
label requires the assembler to compute the differences. If that
computation is wrong you will get junk. The same thing with HLLs. If
the translation of the intermediate code to machine language is not
accurate, you get junk. If the optimizer trashes the code when doing
its thing, you get junk. If the assembler gets the encoding of source
to machine code incorrect, you get junk.
You can write bad code in any language, but I do believe that it is
more difficult for the average programmer to do better in a HLL. The
compiler should help you and the tools available can assist in finding
bugs and some bad practices.
The only real solution to this debate is to use the best language for
the problem at hand. High speed video routines should be done by an
expert in assembly, but a word processing program the size of Word or
the open source equivalent are much better when done in a HLL.
Maintainability, understandability, and portability are better served
in a HLL.
On 22 Feb 2006 16:31:18 -0800, "\\\~\o/~///annabee"
Betov
> It is more difficult to write assembly than to use a HLL.
This has never been demonstrated.
But the reverse, that is that Assembly is easy
and has no limitations, is so massively evident,
that it does not even need any demonstration.
Betov.
Betov
@g47g2000cwa.googlegroups.com:
> The thing is Wannabee, you still have not answered the question I
> posed, "What ideas has Rene used and not used in creating RosAsm based
> on research of the past 20 years?"
Mono-File Programming // Right-Click Functionalities //
Direct output of the PEs // Full Integration // The
simpliest Assembly Syntax // The most powerfull Macros
System for HLL Constructs // The Integration with Win32
Materials // The only Assembly Source Level Integrated
Debugger // The first ever seen Disassembler-ReAssembler
able to do its job in two Clicks // And tons of Tools,
like the Macros Unfolder, the lists Viewers, and so on...
... That achieves into the most productive Assembly
Environnement, ever seen.
> Some of them, I would say:
> 1. Object file creation for linking at a later time (Rene doesn't have
> this, yet just about every Assembler/HLL toolchain has this ability,
> and is considered to be 'a good thing' in computer science.) I would
> place this around, what 1960's based research?
If you do not understand a thing, why do you mean to dicuss?
> 2. Multiply source files. How do many programmers work on the same
> project, if the entire project is in 1 source file?
RosAsm Developements are collective, and all i have to
do, for upgrading a contribution, is to select the Menu
Item saying [Replace Source].
> 3. The internal hashing algorithm doesn't cleanly allow for collisions.
> As a programmer, I would refuse to use a tool that would fail to 2
> separate tokens (or keywords) hashed to the same value, and the tool
> wouldn't differentiate between them simply becuase the hash is the
> same...
???!!!... Ahhh!... This point fully explains all of the
above:
You _really_ believe in Master Randall Hyde insanities.
Well, from that point, really, any discussion would ne
completely useless, as long as if you are able to eat
such shit, your case is a fully disesparated one.
:)
Betov.
Betov
@g44g2000cwa.googlegroups.com:
> May I add to the list?
I am a bit surprised. I must have over-estimate somebody
around here...
Where are you Applications written with FASM, Dragoooon?
Betov.
Chew...@austarnet.com.au
> Chewy509 wrote:
>
> > The thing is Wannabee, you still have not answered the question I
> > posed, "What ideas has Rene used and not used in creating RosAsm based
> > on research of the past 20 years?"
>
> Mono-File Programming // Right-Click Functionalities //
> Direct output of the PEs // Full Integration // The
> simpliest Assembly Syntax // The most powerfull Macros
> System for HLL Constructs // The Integration with Win32
> Materials // The only Assembly Source Level Integrated
> Debugger // The first ever seen Disassembler-ReAssembler
> able to do its job in two Clicks // And tons of Tools,
> like the Macros Unfolder, the lists Viewers, and so on...
>
> ... That achieves into the most productive Assembly
> Environnement, ever seen.
Hi Rene,
I personally find mono-file programming to be non-productive for the
team environment. How does RosAsm manage merging source code from
multiple developers then?
The other points you mentioned do have some credit, but as both DT and
I have listed, there doesn't appear to be any of the benefits from the
last 20years worth of research into langauge/compiler design.
I can see where you are heading with the complete IDE for Win32, but
rather than RosAsm being *really* good at 1 thing, you try to be good
at *all* things, and you unfortunately IMHO just don't make the grade.
What you are aiming for, put simply, is *very* hard to achieve. I do
sincerely give you credit for what you have achieved so far...
Therefore am willing to give you the time to discuss things in a
logically and constructive manner.
Anyway, for a truely one-stop IDE, I really would have expected to have
seen some form of SCM integration. (eg. even if it's only for CVS).
PS. I also find the RosAsm syntax confusing... But this is just a
personal preference thing, so don't look to much into it or take it
personally.
> > Some of them, I would say:
> > 1. Object file creation for linking at a later time (Rene doesn't have
> > this, yet just about every Assembler/HLL toolchain has this ability,
> > and is considered to be 'a good thing' in computer science.) I would
> > place this around, what 1960's based research?
>
> If you do not understand a thing, why do you mean to dicuss?
I know Randy and Steve have gone over this a million times, so I'll
drop this one. (Some of us do work with other languages and tools
beside assembly).
> > 2. Multiply source files. How do many programmers work on the same
> > project, if the entire project is in 1 source file?
>
> RosAsm Developements are collective, and all i have to
> do, for upgrading a contribution, is to select the Menu
> Item saying [Replace Source].
So how does RosAsm handle merging files from multiple sources? Is it
manual? Does it require user intervention? Applications of all sizes
can benefit from being spilt into multiple parts, so that multiple
developers can work on the same application...
If it's truely as you say, then surely there are some scability issues?
I personally can see the mon-file system breaking down even with as few
as 4 or 5 developers all working on the same project. Like who has the
latest copy? Will my merges overwrite anothers work?
> > 3. The internal hashing algorithm doesn't cleanly allow for collisions.
> > As a programmer, I would refuse to use a tool that would fail to 2
> > separate tokens (or keywords) hashed to the same value, and the tool
> > wouldn't differentiate between them simply becuase the hash is the
> > same...
>
> ???!!!... Ahhh!... This point fully explains all of the
> above:
>
> You _really_ believe in Master Randall Hyde insanities.
> Well, from that point, really, any discussion would ne
> completely useless, as long as if you are able to eat
> such shit, your case is a fully disesparated one.
Hasn't it been proven that under certain conditions, that when 2
different tokens/keyword hash to the same value, and that RosAsm
crashes as a result. And wasn't your response, was simply to change the
2nd token to something else to avoid the collision? Or Google, surely
must be failing me...
So what about the other points that both DT and I mentioned?
PS. Nice to see that the Master has had to step in to save the
Apprentice from embarassment... (Reminds me of Sith Lord Betov, to the
rescue of Darth Wannabee - yes it's a cheap Star Wars joke, get over it
:P ).
Betov
news:1140693214....@e56g2000cwe.googlegroups.com:
> Hi Rene,
>
> I personally find mono-file programming to be non-productive for the
> team environment. How does RosAsm manage merging source code from
> multiple developers then?
RosAsm is fully featured with special Functionalities,
for enabling Mono-File-Programming:
* A "TITLE" feature divides the Mono-File, so that the
Editor behaves, just like it would do with Multi-Files,
when required, and like it would do with Mono-files when
required.
* The Menu and the Resources Editor offers features that
make exporting, replacing, importing, as easy as one click.
* The "InInclude" Pre-Parser does a sophisticated job at
sharing "TITLE"s, in between several Applications, with
a "Back&Forth" Mechanisms.
For example (a very significative one), when Ludwig sends to
me an new version of the Debugger, that may as well involve
several TITLEs and Dialogs, the update take me around 10
... seconds.
> The other points you mentioned do have some credit, but as both DT and
> I have listed, there doesn't appear to be any of the benefits from the
> last 20years worth of research into langauge/compiler design.
???!!!... Since when, in the Computers' Languages history
20 last years, was Assembly proposed as a general Development
Language? The last time, was in the earlier days of x86.
Since then, only the oncoming of RosAsm proposed such a
choice, and, up to now, no other Assembler proposes anything
else, that could ever be considered, in that area.
> I can see where you are heading with the complete IDE for Win32,
Yes. But not only.
> but
> rather than RosAsm being *really* good at 1 thing, you try to be good
> at *all* things, and you unfortunately IMHO just don't make the grade.
> What you are aiming for, put simply, is *very* hard to achieve. I do
> sincerely give you credit for what you have achieved so far...
> Therefore am willing to give you the time to discuss things in a
> logically and constructive manner.
You are, in some way right, that _I_ cannot "make the grade'
at everything. But you are missing the point that RosAsm is
under GPL, and under collective developments. My position,
with this, is to develop everything i can, the fastest
possible way. Then, once the direction shown is clearly by
a "nevertheless working fine" draft, this is never too late
for _rewriting_. Several parts of the job have already be
done with much success this way. For example, the Debugger,
for which i wrote a basic trivial first version, that another
volunteer, better than me in that matter, took on charge,
developped, re-write, and pushed to the state of a "state
of Art" Source Level Disasembler, with Tool Tips Infos,
Dynamic Write-Time and Run-Time Break-Points, and so on,
... or like the Assembler first Parsers, that have been
entirely re-organized by another volunteer... or like the
Resource Types By Name, that a third Volunteer implemented
afterward, for the Disassembler, and so on... and so on...
> Anyway, for a truely one-stop IDE, I really would have expected to
> have seen some form of SCM integration. (eg. even if it's only for
> CVS).
>
> PS. I also find the RosAsm syntax confusing... But this is just a
> personal preference thing, so don't look to much into it or take it
> personally.
Arguments? "Personal Preference" does not mean a thing to me.
Readability is the key-word, and Readability is the result
of objective considerations of objective details of the Syntax.
Not any matter of "Personal Preference".
>> > Some of them, I would say:
>> > 1. Object file creation for linking at a later time (Rene doesn't
>> > have this, yet just about every Assembler/HLL toolchain has this
>> > ability, and is considered to be 'a good thing' in computer
>> > science.) I would place this around, what 1960's based research?
>>
>> If you do not understand a thing, why do you mean to dicuss?
>
> I know Randy and Steve have gone over this a million times, so I'll
> drop this one. (Some of us do work with other languages and tools
> beside assembly).
And you give any credibility to these pathetic clowns,
who never did anything thing, rather than to me, who
am not yet senile enough for not knowng of what i have
written?
The RosAsm Symbols Table Management is a real _model_
to consider seriously for anyone who wants to develop
a Language. One of the simpliest ones, one for the
fastest ones, if not the simply the best. Believing
that i could have implemented a Symbols Table Engine
that would refuse Names with conflicting ChechSums,
is nothing but insulting _your_ own intelligency.
>> > 2. Multiply source files. How do many programmers work on the same
>> > project, if the entire project is in 1 source file?
>>
>> RosAsm Developements are collective, and all i have to
>> do, for upgrading a contribution, is to select the Menu
>> Item saying [Replace Source].
>
> So how does RosAsm handle merging files from multiple sources? Is it
> manual? Does it require user intervention? Applications of all sizes
> can benefit from being spilt into multiple parts, so that multiple
> developers can work on the same application...
>
> If it's truely as you say, then surely there are some scability
> issues? I personally can see the mon-file system breaking down even
> with as few as 4 or 5 developers all working on the same project. Like
> who has the latest copy? Will my merges overwrite anothers work?
Same question as above. Same Answer.
:))
>> You _really_ believe in Master Randall Hyde insanities.
>> Well, from that point, really, any discussion would ne
>> completely useless, as long as if you are able to eat
>> such shit, your case is a fully disesparated one.
>
> Hasn't it been proven that under certain conditions, that when 2
> different tokens/keyword hash to the same value, and that RosAsm
> crashes as a result. And wasn't your response, was simply to change
> the 2nd token to something else to avoid the collision? Or Google,
> surely must be failing me...
???!!!... "Proven" ???!!!... Oh! My Goat!!!...
"Lie, lie again: There will always be and idiot for
believing the lie".
Betov.
Betov
212.27.42.129:
> of Art" Source Level Disasembler
"Debugger"!!! Of course!!!
:))
Betov.
Dragontamer
Betov wrote:
> "Dragontamer" <prti...@gmail.com> écrivait news:1140659939.123239.276260
> @g44g2000cwa.googlegroups.com:
>
> > May I add to the list?
>
> I am a bit surprised. I must have over-estimate somebody
> around here...
>
> Where are you Applications written with FASM, Dragoooon?
Overestimated or not, you ignored my post.
Betov; you claim you have taken the best ideas out of the industry
in the past years and put it into RosAsm. I ask _you_ :
Where are your Applications written in HLLs?
Ah, fudge; that is just the whole gorilla pounding chest thing again.
Why don't we be more civilized?
I am a beginner programmer; beginner in all aspects and immature
in my life. I won't hide this fact.
Regardless: if you cannot respond to my argument, I'd just have to
conclude that you don't know how to counter my argument.
And common; these are beginner concepts Betov; I'm a beginner, and
thus think like a Beginner. Shouldn't your "expertise" be more than
enough
to convince me in anything?
Or are you scared that you'd lose a debate between us? :-p That
you'd fail to convince me your point is true?
Ah, there I go again: gorilla "chest pounding".
Just debate Betov. Stop stalling already.
--Dragontamer
\~o/~///annabee
you've
shot off your mouth in ignorance. So you have to resort to name calling
rather than coming back with an intelligent reply.
Cheers,
Randy Hyde//
He is asking me to test all the languages out there. This is a trap. It
takes years to know a good language to all its weaknesses and
strengths. At the least it would take several months, per language,
because you must write some decent sized project with it, to see all
its performances both in terms of code size, complexity, speed of
production, stability of the library etc etc.
There are exceptions, like HLA, where a glance at some code imidiatly
tells you that this is useless, but for some lamguages, it might not be
as immidiatly clear.
Yes, so its an idiotic suggestion. If you know assembly, you
automatically know every language, because you now know the language of
the CPU, and then can judge other languages based on that. And it is
clearly shown, by RosAsm that the only thing that makes HLL have any
validity at all, is because of the talentless poor capacity of the
avarage assemblers. The "tools" we have had for doing asm in the past
are pretty much in the "ao-useless" catagory. This is what has given
asm a bad reputation. asm itself is the very best of languages, the
least complicated, the most productive, if given a chance, by haveing a
good tool for the job. In no way is there any reason to think that any
spesific language, who makes abstractions on the asm, could in anyway
do the job better then the real thing.
Betov
@u72g2000cwu.googlegroups.com:
> I ask _you_ :
>
> Where are your Applications written in HLLs?
I begun programming on IBM in 1968, boy, and my HLL
"performances" are far away in some trash-bin, mind
you.
:))
I ask _you_ :
Where are your Applications written in FASM. Period.
You introduced yourself, here, as a FASM user. Then,
taking the paths open by our prefered swindler, you
were arguing stupid arguments about comparing FASM
and RosAsm, that tends to make me think that you hardly
know a couple of details about FASM, and almost nothing
about RosAsm. Therefore my question.
As i have alredy said elsewhere, i am always good will
to discuss about the avantages and inconvenient of this
and that Assembler. But not with BalBlating clowns. If
you have nothing to show, shut-up. If you have something
to show, show it, so that i could know see i am talking
with. Period.
Betov.
\~o/~///annabee
this claim was made several years ago when Delphi was barely 10 years
old). And after all that experience, he still hadn't figured out how to
do a linked list in Delphi. Look up the post where he bragged about how
easy it was to do linked lists in RosAsm and he had been unable to do
that in Delphi. You'd think after 10 years of using Delphi (and
apparently Turbo Pascal before that, according to some recent posts) he
would have figured out how to do linked lists in Pascal.
Cheers,
Randy Hyde //
May you die in your sleep soon master PDF!
I have ten years, _at least_ of _Pascal_ experience. 10 might be
somewhat correct. Its a very rough estimate. I didnt do any
programming from late 1996 to late 1997 for instance, a whole year
away. And yes, miricles of miricles, I spend more time in this ng then
with programming, I spend more time with playing games then with
programming, and I even spend some small time with my significant
other, friend(s) :))
For instance, now I am playing battlefield2 for HOURS everyday, and its
an awsome game. Its really a terrifically funny game.
But why I am explaining myself to you?. You are an insignificant
asshole. And your words will never count for anything.
Dragontamer
\~o/~///annabee wrote:
> //IOW, he's asking questions for which you have no answer because
> you've
> shot off your mouth in ignorance. So you have to resort to name calling
>
> rather than coming back with an intelligent reply.
> Cheers,
> Randy Hyde//
>
> He is asking me to test all the languages out there. This is a trap. It
> takes years to know a good language to all its weaknesses and
> strengths. At the least it would take several months, per language,
> because you must write some decent sized project with it, to see all
> its performances both in terms of code size, complexity, speed of
> production, stability of the library etc etc.
It was a "trap" I expected you not to take; let alone give a 2nd
thought about.
The trap was there to prove a point. The point is obviously so far
beyond you,
maybe I should slam it on you with straight english.
You cannot generalize "HLLs" into one group, just as you cannot learn
all HLLs,
you cannot generalize all HLLs.
> There are exceptions, like HLA, where a glance at some code imidiatly
> tells you that this is useless, but for some lamguages, it might not be
> as immidiatly clear.
>
> Yes, so its an idiotic suggestion. If you know assembly, you
> automatically know every language, because you now know the language of
> the CPU, and then can judge other languages based on that.
I can write any x86 code with C code (as demonstrated with the Bochs
emulator). Does this mean every C programmer knows every other language
out there?
If not, then why not. What makes assembly more special than C?
(because I can create a virtual machine in C, and have all x86 assembly
instructions
running on a C machine. So the "machine" assembly is running on is
really just the C
language)
A few posts up, Algol was the language of the CPU. Does that make every
person
who knows Algol know every language?
--Dragontamer
Dragontamer
Betov wrote:
> "Dragontamer" <prti...@gmail.com> écrivait news:1140705718.731793.34450
> @u72g2000cwu.googlegroups.com:
>
> > I ask _you_ :
> >
> > Where are your Applications written in HLLs?
>
> I begun programming on IBM in 1968, boy, and my HLL
> "performances" are far away in some trash-bin, mind
> you.
And you base all your experiances on HLL programming with concepts
over 30 years old?
> I ask _you_ :
>
> Where are your Applications written in FASM. Period.
>
> You introduced yourself, here, as a FASM user. Then,
> taking the paths open by our prefered swindler, you
> were arguing stupid arguments about comparing FASM
> and RosAsm, that tends to make me think that you hardly
> know a couple of details about FASM, and almost nothing
> about RosAsm. Therefore my question.
I am an C programmer who uses Fasm to modify my programs.
Most are know nothing demos anyway, nothing of use.
I fail to see what this has to do with the argument at hand however.
> As i have alredy said elsewhere, i am always good will
> to discuss about the avantages and inconvenient of this
> and that Assembler. But not with BalBlating clowns. If
> you have nothing to show, shut-up. If you have something
> to show, show it, so that i could know see i am talking
> with. Period.
I have nothing to show but my argument. And there is nothing
_but_ the argument that should be important.
It is all logic I wish to participate in.
If my premises are true; and my logic valid; then my argument must
be true.
I am a beginner, and I would be lying if I said anything different. But
at
least I base my knowledge on modern concepts, and not on programming
from 1968.
Nonetheless, none of this changes any argument :-p I already told you
that I'm a beginner; and thus, you should be able to *easily*
demonstrate
where I am incorrect.
Because if I'm not incorrect, then I am correct; correct? :-p
--Dragontamer
Dragontamer
Dragontamer wrote:
> I have nothing to show but my argument. And there is nothing
> _but_ the argument that should be important.
I forgot to add this:
As for what "experiance" is useful for; it is useful to copy those
who are obviously experts in their field.
Take Tim Sweeney from Epic Games. Conducted a project
consisting of over 500,000 lines of code.
IMO, his opinion is worth more to me than your opinion.
His opinion on assembly language?
http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
=======
Productivity is just as important
Will gladly sacrifice 10% of our performance for 10% higher
productivity
We never use assembly language
=======
Now, while I don't agree with him exactly; if we go by "who has
done the bigger project" thing, Tim Sweeney conducted the largest
project so far.
I also posted this link up for the origional poster :)
He goes on on what he thinks are great ideas from the industry, and
has a few highlights from Haskell, and highlights mistakes from
"current languages" (none of which, I might add, have been addressed
by Betov yet)
Here they are for reference:
=============
Solved problems:
Random memory overwrites
Memory leaks
Solveable:
Accessing arrays out-of-bounds
Dereferencing null pointers
Integer overflow
Accessing uninitialized variables
50% of the bugs in Unreal can be traced to these problems!
=============
Now, I hate to use "his words in my mouth" sort of thing, but if Betov
doesn't
want to listen to me, I should do this as a college essay. Use someone
else's
words in my argument, and copycat the argument :-p
--Dragontamer
Dragontamer
\~o/~///annabee wrote:
> For instance, now I am playing battlefield2 for HOURS everyday, and its
> an awsome game. Its really a terrifically funny game.
I actually never enjoyed the game. There aren't many FPS I like though,
so
even if the best FPS hit me in the head, I probably wouldn't notice
anyway.
Soldat is my shooting game; 2d arcade action networked glory.
Simplified; sorta like how Halo simplified shooters... it took a couple
of
stuff from the old game "Abuse" as well.
--Dragontamer
Betov
@e56g2000cwe.googlegroups.com:
> I have nothing to show but my argument.
True.
:)
Betov.
Dragontamer
Betov wrote:
> "Dragontamer" <prti...@gmail.com> écrivait news:1140724284.075417.101850
> @e56g2000cwe.googlegroups.com:
>
> > I have nothing to show but my argument.
>
> True.
Wow, we agree on something :-p
--Dragontamer
rand...@earthlink.net
Betov wrote:
> "Dragontamer" <prti...@gmail.com> écrivait news:1140705718.731793.34450
> @u72g2000cwu.googlegroups.com:
>
> > I ask _you_ :
> >
> > Where are your Applications written in HLLs?
>
> I begun programming on IBM in 1968, boy, and my HLL
> "performances" are far away in some trash-bin, mind
> you.
This is the guy, mind you, who berates others for not providing URLs to
their past work. I guess it's okay for his past code to wind up the
trash (no doubt, where it belongs), but other people aren't afforded
this luxury.
As you say, Rene, where's the URL?
>
> :))
>
> I ask _you_ :
>
> Where are your Applications written in FASM. Period.
And he asked you where are your apps written in a HLL. Just as fair a
question as the one you're asking.
No doubt, your HLL experience consists of some COBOL or FORTRAN code
:-)
Good luck convincing us that you know what belongs in a language, or
what HLLs are all about, when your last experiences with such languages
was back in 1968. Things *have* changed a bit over the past 40 years,
you know?
>
> You introduced yourself, here, as a FASM user. Then,
> taking the paths open by our prefered swindler, you
> were arguing stupid arguments about comparing FASM
> and RosAsm, that tends to make me think that you hardly
> know a couple of details about FASM, and almost nothing
> about RosAsm. Therefore my question.
If what he does know makes him realize that he can accomplishing things
with FASM that cannot be done with RosAsm, then he already knows enough
to make the argument.
>
> As i have alredy said elsewhere, i am always good will
> to discuss about the avantages and inconvenient of this
> and that Assembler. But not with BalBlating clowns. If
> you have nothing to show, shut-up. If you have something
> to show, show it, so that i could know see i am talking
> with. Period.
IOW, anyone who doesn't buy your nonsense about RosAsm being the
fastest and most powerful assembler (which is false on both counts)
need not enter the debate, eh?
Cheers,
Randy Hyde
rand...@earthlink.net
Betov wrote:
>
> Mono-File Programming // Right-Click Functionalities //
> Direct output of the PEs // Full Integration // The
> simpliest Assembly Syntax // The most powerfull Macros
> System for HLL Constructs // The Integration with Win32
> Materials // The only Assembly Source Level Integrated
> Debugger // The first ever seen Disassembler-ReAssembler
> able to do its job in two Clicks // And tons of Tools,
> like the Macros Unfolder, the lists Viewers, and so on...
>
> ... That achieves into the most productive Assembly
> Environnement, ever seen.
Where is the research that proves this?
You're just making this nonsense up. And no one believes (nor should
they). For example, exactly how does the "first ever seen
disassembler-reassembler" improve programmer productivity? How many
programmers need to disassemble and then immediately reassemble small
programs (that the disassembler can process without error, that is)?
Particularly when the result cannot be modified without breaking the
code? You call this "productivity"?
How does "direct output of PEs" help productivity? Particularly when
the person needs to link their code with other languages, or port the
code to Linux?
As for your "powerful macros". What a joke. HLA, MASM, TASM, and even
FASM do a much better job. Indeed, with high-level assemblers like HLA,
MASM, and TASM the user doesn't even have to write the macros or worry
about them, the statements are built into the language. Zero work to
create them. That's an infinite amount of additional productivity.
The "integration with Win32..." doesn't do a Linux programmer one bit
of good. Indeed, as RosAsm is *useless* for anything other than
Windows, trying to claim it is the most productive assembly environment
is completely false. Gas and the lamest text editor out there beats
RosAsm under Linux any day. Because RosAsm doesn't run under Linux.
Pick any other non-Win32 OS and you get the same answer.
And if you think that RosAsm's syntax is simple, then you don't
understand anything about grammars. RosAsm's syntax is ambiguous.
Hardly an example of "simple".
>
>
> > Some of them, I would say:
> > 1. Object file creation for linking at a later time (Rene doesn't have
> > this, yet just about every Assembler/HLL toolchain has this ability,
> > and is considered to be 'a good thing' in computer science.) I would
> > place this around, what 1960's based research?
>
> If you do not understand a thing, why do you mean to dicuss?
He understands perfectly well. It's you who doesn't seem to understand
a well-embraced capability that nearly all professional software
development tools support. Just because you've poorly designed RosAsm
and that doesn't allow you to implement separate compilation doesn't
mean the feature is bad. You'd like to make people believe this, in
order to make your product look better, but most programmers are a
little smarter than you'd like to think they are. When absolute
*beginners* see the problem with your design, you ought to carefully
reconsider what you preach all the time. Have you noticed how all the
other assemblers wound up moving in that direction (e.g., GoAsm)?
People don't put it in early version of their software because it's
more difficult. But most people have designed their assemblers to allow
the inclusion later on. That's the problem with RosAsm. Your "generate
PEs directly" and "burying the source in the EXE file" prevents this.
You claim that separate compilation is a bad idea. But the truth is,
you're just unable to do it given RosAsm's design, so you try to pass
it off as a bad concept, rather than just admiting you have a bad
design. You aren't fooling anyone. Everyone knows your design is crap.
And the lack of object-file capability is the main reason you have so
few users.
>
>
> > 2. Multiply source files. How do many programmers work on the same
> > project, if the entire project is in 1 source file?
>
> RosAsm Developements are collective, and all i have to
> do, for upgrading a contribution, is to select the Menu
> Item saying [Replace Source].
Uh-huh. You really don't understand the concept. At all.
>
>
> > 3. The internal hashing algorithm doesn't cleanly allow for collisions.
> > As a programmer, I would refuse to use a tool that would fail to 2
> > separate tokens (or keywords) hashed to the same value, and the tool
> > wouldn't differentiate between them simply becuase the hash is the
> > same...
>
> ???!!!... Ahhh!... This point fully explains all of the
> above:
>
> You _really_ believe in Master Randall Hyde insanities.
Could it possibly be that he arrived at this opinion on his own? Like
so many other people have?
> Well, from that point, really, any discussion would ne
> completely useless, as long as if you are able to eat
> such shit, your case is a fully disesparated one.
Of course. He's a little too bright to be misled by your nonsense. So
attempting to convince him of your point of view is completely useless.
Blame it on me all you want. You like to blame everything bad that
happens to you on me, but the truth is the population in general tends
to discount everything you say. And that would be true even if I
weren't around to point out all your nonsense.
Cheers,
Randy Hyde
Chew...@austarnet.com.au
>
> How does "direct output of PEs" help productivity? Particularly when
> the person needs to link their code with other languages, or port the
> code to Linux?
Oh come on Randy, at least I acknowledge that RosAsm is targetted for
Windows only. Whining about it doesn't support Linux (which isn't a
desgin criteria), is like whining that MSWord can't work on Linux.
<snip>
I personally don't care about the internals of RosAsm, however if a
programming tool can't be used with another language, then it
immediately creates a barrier to adoption and general usage. RosAsm as
I see it, is fine for your small 4K type demos, but for larger projects
(Millions of lines of code, with 4-5 developers working with on
multiply parts and possibly in different languages), RosAsm shouldn't
even be considered.
Let's take for example, a GUI desginer using (gasp) VisualBasic or
Delphi for the GUI, but the core of the processing is done assembler
(for various reasons), RosAsm simply put cannot be a viable tool for
this type of project. There are some *fantastic* GUI building
toolkits/applications available that generate either VB or VC++, but if
RosAsm cannot be integrated into a larger environment, it has no place
being there.
<snip>
> > ???!!!... Ahhh!... This point fully explains all of the
> > above:
> >
> > You _really_ believe in Master Randall Hyde insanities.
>
> Could it possibly be that he arrived at this opinion on his own? Like
> so many other people have?
While I have taken some interest in the work of others, both of you
(Randy and Rene) know I have asked about hashing algorithms for
compilers/assemblers myself in this very NG. I have tested several
hashing algorithms including the one in RosAsm, and found that the way
that RosAsm handles hashing and collisions to be sub-par. I think that
qualifies that, I have come to this collision myself.
> > Well, from that point, really, any discussion would ne
> > completely useless, as long as if you are able to eat
> > such shit, your case is a fully disesparated one.
>
> Of course. He's a little too bright to be misled by your nonsense. So
> attempting to convince him of your point of view is completely useless.
> Blame it on me all you want. You like to blame everything bad that
> happens to you on me, but the truth is the population in general tends
> to discount everything you say. And that would be true even if I
> weren't around to point out all your nonsense.
The thing is Rene, you still have not answered most of the questions I
have posed to both yourself and Wannabee. So I would like to ask a few
very direct questions:
1. Why do *you* believe that creation of object files for linking at a
later stage is useless?
2. What advantages does single file source have over multi-ple source
files? How do you handle security rights within the source code? I'll
give you an example.
The French Armée de Terre has requested a new application which works
with offline encryption systems, in conjunction with NATO. The actual
encryption algorithm used is classified and is only known to 2
programmers on a team of 20 programmers developing the application. The
other 18 do not need to know (and are officially not to know) what the
algorithm is or how it works. (They just call it with correct inputs).
Since one of the requirements of the application is EAL7 certification,
(requires formal mathematical proof of function and are typically
written in Assembly), an Assembler is needed. How can an assembler
which only works with a single source file be used in this scenario?
The brings up another point (I haven't looked into this), but AFIAK
RosAsm embeds the source code (in ASCII form) into the application, can
this be stripped out?
3. OOP has had a lot of research in the past 20-30 years, and is
considered to be a valuable programming methodology. Why have you
choosen not to directly support or provide a macro based framework for
OOP? Or at least provide a few examples which others could build upon?
4. You promote RosAsm as the "most productive Assembly Environnement,
ever seen." Yet you don't provide SCM (Source Code Management)
integration? Just about every other decent IDE does (HLL or otherwise).
So I have to ask, since you don't provide SCM, why do you believe SCM
integration to be useless for RosAsm?
Chew...@austarnet.com.au
Chew...@austarnet.com.au wrote:
> I think that
> qualifies that, I have come to this collision myself.
Typo fix: I think that qualifies that, I have come to this *conclusion*
myself.
\~o/~///annabee
emulator). Does this mean every C programmer knows every other language
out there?
If not, then why not. What makes assembly more special than C?
--Dragontamer
//
The only people able to write decent C are assembly programmers.
Herbert is one example. Paul Hsieh is another. Theese people know
assembly, and they know exactly/rougly what C outputs. They also know
the machine, very well, and yes, therefore they may be able to write
examplary efficient C programs. But this has nothing todo with the C
language, AT ALL. It has everything todo with the efforts of those two
persons. Their private investment of time and effort to learn the art
of programming. They went beyond the C.
A beginner C programmer, knowng nothing about the machine or asm, will
NOT be able to write efficent real life applications.
The thing is totally diffrent with asm. In asm, even a beginner will
write 10 times as efficient code as a beginner C programmer using a
compiler. Even when the particular code itself is better when done i C,
the application written in asm will outperform a typical beginner C app
by at least an order of magnitude. And with a really useful tool, like
RosAsm, he will also accomplish this in half the time of using a HLL.
The reason is, the the asm beginner, will very soon learn, in a lot
less time, what the machine is doing and how to make things fast. And
doing asm he will not waste a fragment of the code the compiler does.
Also, most task in a real application are trivially simple. Just a
matter of time, not of using the brain, and by default, asm is so fast
that those task all run like bats out of hell, or in times that counts
for nope. Under win32 you will face the limits of the OS, and hardware
much earlier than you will face the limits of assembly.
Betov
news:1140733947.7...@z34g2000cwc.googlegroups.com:
> Good luck convincing us that you know what belongs in a language
Good luck convincing us that you know what an Assembler
is, after having written such a packet of shit, as HLA.
:)
Betov.
Betov
@t39g2000cwt.googlegroups.com:
> While I have taken some interest in the work of others, both of you
> (Randy and Rene) know I have asked about hashing algorithms for
> compilers/assemblers myself in this very NG. I have tested several
> hashing algorithms including the one in RosAsm, and found that the way
> that RosAsm handles hashing and collisions to be sub-par. I think that
> qualifies that, I have come to this collision myself.
If you just took a quick look at the CheckSum64
Routine, _yes_ of course, there _are_ collisions.
Evidently. How could it be collisions free? They
are simply extreemely few, at the 64 Bits level.
Then, there is the 16 Bits level of the real Table,
where collision are, of course, fully assumed. Which
idiot could believe otherwise?
It seems you have simply been unable to read the
main Routines for reading and writting.
> 1. Why do *you* believe that creation of object files for linking at a
> later stage is useless?
It is not useless for HLLers. I simply do NOT work
for HLLers. Mind you, i perfectly know that, outputing
Obj Files, Lib Files, and so on, would immidiately
multiply the user base by 20. I am not still completely
senile.
> 2. What advantages does single file source have over multi-ple source
> files?
The massive advantages of simplicity in the edition and
in the maintainance. A RosAsm Project is _ONE_ File: The
PE itself. Period.
> How do you handle security rights within the source code? I'll
> give you an example.
>
> The French Arm‚e de Terre has requested a new application which works
> with offline encryption systems, in conjunction with NATO. The actual
> encryption algorithm used is classified and is only known to 2
> programmers on a team of 20 programmers developing the application. The
> other 18 do not need to know (and are officially not to know) what the
> algorithm is or how it works. (They just call it with correct inputs).
> Since one of the requirements of the application is EAL7 certification,
> (requires formal mathematical proof of function and are typically
> written in Assembly), an Assembler is needed. How can an assembler
> which only works with a single source file be used in this scenario?
I do not work for Crime&Co.
> The brings up another point (I haven't looked into this), but AFIAK
> RosAsm embeds the source code (in ASCII form) into the application, can
> this be stripped out?
???!!!...
< http://betov.free.fr/SourceKiller.zip >
> 3. OOP has had a lot of research in the past 20-30 years, and is
> considered to be a valuable programming methodology. Why have you
> choosen not to directly support or provide a macro based framework for
> OOP? Or at least provide a few examples which others could build upon?
There is, at least, one RosAsm user who writes OOA, on
a daily Basis. OOA does not need any particular things
in an Assembler.
Nevertheless a real OOA Pre-Parser is planed since some
time, and it will be implemented some day, when i will
have nothing better to do, if no other volunteer takes
it in charge.
> 4. You promote RosAsm as the "most productive Assembly Environnement,
> ever seen."
Fact. Compare how many significative Applications written
by the couple of RosAsm users, and how many for the other
Assemblers and their user Bases, that is around 15 or 20
times bigger.
> Yet you don't provide SCM (Source Code Management)
> integration? Just about every other decent IDE does (HLL or otherwise).
> So I have to ask, since you don't provide SCM, why do you believe SCM
> integration to be useless for RosAsm?
Assembly Programmers manage their Sources the way they
like. Period. The Tools dedicated for this kind of job
are for HLLers, who, by definition, cannot know what
they are doing. Nevertheless, RosAsm is more than enough
featured with all required functionalities, that could
help the Maintaince of an Assembly Programmer, like the
"Progressive Back-Up". Your questions show nothing but at
what extend you are ignorant of the Tool Functionalities,
basing your opinions on insanities spreaded here and there,
by unsignificants ass-holes, like Randall Hyde.
Betov.
Dragontamer
\~o/~///annabee wrote:
> // can write any x86 code with C code (as demonstrated with the Bochs
> emulator). Does this mean every C programmer knows every other language
> out there?
>
> If not, then why not. What makes assembly more special than C?
>
> --Dragontamer
> //
>
> The only people able to write decent C are assembly programmers.
> Herbert is one example. Paul Hsieh is another. Theese people know
> assembly, and they know exactly/rougly what C outputs. They also know
> the machine, very well, and yes, therefore they may be able to write
> examplary efficient C programs. But this has nothing todo with the C
> language, AT ALL. It has everything todo with the efforts of those two
> persons. Their private investment of time and effort to learn the art
> of programming. They went beyond the C.
>
> A beginner C programmer, knowng nothing about the machine or asm, will
> NOT be able to write efficent real life applications.
>
> The thing is totally diffrent with asm. In asm, even a beginner will
> write 10 times as efficient code as a beginner C programmer using a
> compiler. Even when the particular code itself is better when done i C,
> the application written in asm will outperform a typical beginner C app
> by at least an order of magnitude. And with a really useful tool, like
> RosAsm, he will also accomplish this in half the time of using a HLL.
Efficiency has nothing to do with the knowledge of different languages.
And while most of what you say is true; it has nothing to do with my
question or point.
Let me say my question again:
How does learning assembly language "automatically" make you know
all other languages?
--Dragontamer
Dragontamer
Betov wrote:
> Chew...@austarnet.com.au écrivait news:1140750153.918163.301580
> @t39g2000cwt.googlegroups.com:
> > later stage is useless?
>
> It is not useless for HLLers. I simply do NOT work
> for HLLers. Mind you, i perfectly know that, outputing
> Obj Files, Lib Files, and so on, would immidiately
> multiply the user base by 20. I am not still completely
> senile.
I dunno about you Chewy, but I'd classify this as avoiding the question
:)
> > 2. What advantages does single file source have over multi-ple source
> > files?
>
> The massive advantages of simplicity in the edition and
> in the maintainance. A RosAsm Project is _ONE_ File: The
> PE itself. Period.
The advantage of multiple source code files, is that the code
is logically stored in different files. Therefore; you don't spend
so much time searching for a specific routine; or specific data;
it is in the file you want.
Example: if you want to
> > How do you handle security rights within the source code? I'll
> > give you an example.
> >
> > The French Arm,e de Terre has requested a new application which works
> > with offline encryption systems, in conjunction with NATO. The actual
> > encryption algorithm used is classified and is only known to 2
> > programmers on a team of 20 programmers developing the application. The
> > other 18 do not need to know (and are officially not to know) what the
> > algorithm is or how it works. (They just call it with correct inputs).
> > Since one of the requirements of the application is EAL7 certification,
> > (requires formal mathematical proof of function and are typically
> > written in Assembly), an Assembler is needed. How can an assembler
> > which only works with a single source file be used in this scenario?
>
> I do not work for Crime&Co.
I dunno about you Chewy, but I'd classify this as avoiding the question
(again)
:)
> > Yet you don't provide SCM (Source Code Management)
> > integration? Just about every other decent IDE does (HLL or otherwise).
> > So I have to ask, since you don't provide SCM, why do you believe SCM
> > integration to be useless for RosAsm?
>
> Assembly Programmers manage their Sources the way they
> like. Period. The Tools dedicated for this kind of job
> are for HLLers, who, by definition, cannot know what
> they are doing. Nevertheless, RosAsm is more than enough
> featured with all required functionalities, that could
> help the Maintaince of an Assembly Programmer, like the
> "Progressive Back-Up". Your questions show nothing but at
> what extend you are ignorant of the Tool Functionalities,
> basing your opinions on insanities spreaded here and there,
> by unsignificants ass-holes, like Randall Hyde.
Wow.
How do you track where and when bugs enter a program without
progressive backups?
Oh wow; bug doesn't exist in version 1.52, but it exists in version
1.53 and
up. Take a guess where I'm going to look for the bug?
2. With progressive backups, you can always "take a step back" if you
think you refactored your code incorrectly; no matter how long you've
been working on version 2.60, you can always go back to version 2.1
Just the knowledge alone allows you to code more aggressivly and
work more efficiently; knowing that you can isolate bugs quickly should
they arrive, and knowing you can always go back if you royally screw
over the code.
--Dragontamer
\~o/~///annabee
languages. And while most of what you say is true; it has nothing to do
with my
This answer was to the question, and I belive it was yours:
" What makes assembly more special than C?"
//
Let me say my question again:
How does learning assembly language "automatically" make you know
all other languages?
--Dragonlamer
//
What I said was this:
//If you know assembly, you automatically know every language, because
you now know the language of the CPU, and then can judge other
languages based on that//
I want to restate it : The processor only has one real language. Asm is
this "language".
So to know asm, is to know all true languages the computer really has.
And when you do, you can judge other fake languages from this
viewpoint. I did not mean that you will learn C from using asm, that
would be strange, but you will learn better programming technics from
using asm.
rand...@earthlink.net
Chew...@austarnet.com.au wrote:
> randy wrote:
> >
> > How does "direct output of PEs" help productivity? Particularly when
> > the person needs to link their code with other languages, or port the
> > code to Linux?
>
> Oh come on Randy, at least I acknowledge that RosAsm is targetted for
> Windows only. Whining about it doesn't support Linux (which isn't a
> desgin criteria), is like whining that MSWord can't work on Linux.
He listed this as a feature that improves productivity.
Exactly how does this feature improve productivity?
He can state that it's limited to Win32 all he wants, and that's fine.
But listing this as an item that improves productivity is stupid.
>
> The thing is Rene, you still have not answered most of the questions I
> have posed to both yourself and Wannabee. So I would like to ask a few
> very direct questions:
>
> 1. Why do *you* believe that creation of object files for linking at a
> later stage is useless?
I can answer that for him. The truth is his design does not allow this.
And it's not easy to modify his program to allow this. So rather than
fess up and admit that his design (burying the source code in the EXE,
the root of the problem) is bad, he tries to convince people that they
don't really need this facility.
>
> 2. What advantages does single file source have over multi-ple source
> files?
The better question isn't about the files themselves, but about the
assemblers. What advantage does an assembler that *only* allows
single-file applications have over an assembler that supports multiple
files. Particularly when those other assemblers can handle single
files, if that's what the author really wants to do?
>
> The brings up another point (I haven't looked into this), but AFIAK
> RosAsm embeds the source code (in ASCII form) into the application, can
> this be stripped out?
Yes, using a separate utility. You can also save the source file as an
ASCII text file.
>
> 3. OOP has had a lot of research in the past 20-30 years, and is
> considered to be a valuable programming methodology. Why have you
> choosen not to directly support or provide a macro based framework for
> OOP? Or at least provide a few examples which others could build upon?
Very simple. He doesn't know anything about OOP.
>
> 4. You promote RosAsm as the "most productive Assembly Environnement,
> ever seen." Yet you don't provide SCM (Source Code Management)
> integration? Just about every other decent IDE does (HLL or otherwise).
> So I have to ask, since you don't provide SCM, why do you believe SCM
> integration to be useless for RosAsm?
Because he takes the point of view that one master developer is
responsible for merging everyone else's changes into the whole program.
I.e., the role he has been fulfilling for RosAsm. And although RosAsm
is roughly 80,000 or so lines of code, the truth is that it's just a
collection of *different* programs that are all merged into the same
executable. Other than namespace pollution problems, it's not *really*
a case of a half-dozen or so people working on the same code.
Typically, you get one or two people working on the individual programs
that form the RosAsm collection. As such, Rene really hasn't
experienced the problems associated with a half-dozen people working on
the *same* code.
Cheers,
Randy Hyde
rand...@earthlink.net
\~o/~///annabee wrote:
>
> The thing is totally diffrent with asm. In asm, even a beginner will
> write 10 times as efficient code as a beginner C programmer using a
> compiler.
Prove this statement.
Your own code that you've posted here certainly doesn't support this
hypothesis.
> Even when the particular code itself is better when done i C,
> the application written in asm will outperform a typical beginner C app
> by at least an order of magnitude.
"at least"? Hardly.
Back in the days of the 8088 you could make claims like this. Not
today. As an instructor, I've seen lots of beginning C code and lots of
beginning assembly code. None of it was particularly better than the
other. And certainly in terms of the usage of machine instructions, the
C-generated machine code was much better than the hand-generated
assembly code. And as those beginning assembly programmers had yet to
learn the assembly programming paradigm, their assembly coding style
wasn't any better than the C programmer's style. Neither really held
an advantage. This is one of the main reasons people seem to think that
there is no benefit to using assembly.
> And with a really useful tool, like
> RosAsm, he will also accomplish this in half the time of using a HLL.
Prove this.
And using yourself as an example, a statistical sample of one, is no
proof. Just because you never really learned how to program well in
Pascal/Delphi doesn't prove that assembly is a better choice for other
programmers.
>
> The reason is, the the asm beginner, will very soon learn, in a lot
> less time, what the machine is doing and how to make things fast.
You've been at it for at least two years now. And your code isn't at
all amazing in the performance department. You even claim to still be a
beginner at this sort of stuff. Now granted, you claimed to have
programmed in Delphi for 10 years and it's clear you didn't learn much
about Pascal/Delphi in those 10 years, so this statement may certainly
apply to you. But let me suggest that most people learn HLLs a little
bit faster than you do. And they also seem to master assembly a little
faster than you do. So again, using yourself as an example of how the
world operates isn't very bright.
> And
> doing asm he will not waste a fragment of the code the compiler does.
Let's see: compilers tend to use a lot of different machine
instructions. The average RotAsm programmer, using Rene's suggestions,
use only a handful of instructions. It seems to me that it's the RotAsm
programmer who is wasting opportunities here.
Now a *real* assembly programmer, one who takes advantage of the full
instruction set, can do some amazing things. But that's not the
"beginner" that you've been talking about.
> Also, most task in a real application are trivially simple. Just a
> matter of time, not of using the brain, and by default, asm is so fast
> that those task all run like bats out of hell, or in times that counts
> for nope. Under win32 you will face the limits of the OS, and hardware
> much earlier than you will face the limits of assembly.
And you fact the limitations of Win32 much earlier than you face the
limits of HLLs like C/C++. So what's your point?
Cheers,
Randy Hyde
Alex McDonald
> What I said was this:
>
> //If you know assembly, you automatically know every language, because
> you now know the language of the CPU, and then can judge other
> languages based on that//
>
> I want to restate it : The processor only has one real language. Asm is
> this "language".
> So to know asm, is to know all true languages the computer really has.
I really don't agree here (yes, I know that sounds predictable, but
let's see if I can persuade you otherwise).
My PC has the capability to read text to me. I have the ability to
speak to my PC, and it will type the text into my word processor, or
follow my commands. The natural language of _my_ PC is English.
My PC is a collection of electrons moving in response to quantum
mechnical effects. Electrons strike the phosphor on the screen in front
of me; when I press keys, electrons move in predefined paths inside my
PC. The natural language of _my_ PC is electrons.
There are layers of abstraction at work here; there isn't a single
language. There are descriptions and formalisations at every level;
assembler addresses one of them, VHDL addresses another, LISP a third,
and so on, at every level.
If all languages were like hammers, then the only problems we could
solve would be those that could survive a really good beating.
> And when you do, you can judge other fake languages from this
> viewpoint. I did not mean that you will learn C from using asm, that
> would be strange, but you will learn better programming technics from
> using asm.
Again, no. Programming techniques are best learned by using tools that
fit, not a hammer on every occasion. Sometimes maths, sometimes
pseudo-code, sometimes just plain English; and rarely assembler. I have
a strong objection to books that try to teach algorithms using, for
instance, only C. Not that I dislike C (in fact, I can't even write it,
so dislike would be difficult) but because it's like trying to decribe
how to build an igloo in Swahili. Innuit is far more expressive on the
subject of constructing a home from snow.
--
Regards
Alex McDonald
Betov
news:1140803489.4...@p10g2000cwp.googlegroups.com:
> rarely assembler
In your case, sure.
:)
Betov.
Dragontamer
I don't think so. There are a couple of stuff I've learned in every
exotic
computer languages that Assembly doesn't express. Yes, Assembly
*can* express say, Continuations, but not as efficiently as Scheme
or Haskell can do Continuations.
In assembly, you cannot "return" a function that has been partially
completed.
Actually, there is one thing Assembly can't represent at all: functions
as data. And no, i don't mean "function pointers", i'm talking
functions
as data.
For example: in Haskell there is a function called "foldr" (fold to the
right),
which basically turns *any* given function into a new function iterated
against
a list. For example, "foldr +" would return a new function that would
apply
the + sign across a list.
You cannot , in assembly, create a program that reads in data from the
hard drive,
and then combine functions together during runtime and creates new
functions. Actually,
you can; and the way you'd implement it is by creating a new scripting
language;
so that you can "compile" or "interpret" code as you run (so you can
create
new functions during runtime) Assembly alone cannot solve this problem;
you'd
need a high level language to represent the functions; unless you wish
to deal
with opcodes directly to create a function.
In fact, this programming technique (combining functions together
during
runtime) is grouped together in the "functional programming style" Now,
you
may call me "cheating" because all of this can be done under "Lisp",
which
was considered the assembly language of Lisp Machines. (a much more
powerful assembly language than x86 to say the least)
But anyway, thats my point: you cannot learn these programming
techniques
from assembly. You can *apply* them to assembly after you learned them,
but
you cannot learn them just from assembly language.
Other programming techniques assembly doesn't work so well with:
Currying: that is, "1 +" returns a function. In fact, in Haskell, you
can
define a function as:
increment = 1 +
And increment 5 would turn into 1 + 5. Mind you, this is not currying
yet.
Currying is when you have a function that returns a function to process
the rest of the parameters. Example, if you have a function that takes
2
parameters...
distance x1 y1 x2 y2
/\ Gets the distance between 2 points
distance would be a function with 4 parameters
(distance x1) would create a function with 3 parameters.
(distance x1 y1) would create a function with 2 parameters.
etc. etc.
Lazy evaluation is also not done well in Assembly language. Well, lets
just say, the entire field of "Functional programming" doesn't fit with
x86 assembly language; all those programming techniques you will
*never* learn unless you took a step away from assembly.
--Dragontamer
Alex McDonald
Betov wrote:
> "Alex McDonald" <alex...@btopenworld.com> écrivait
> news:1140803489.4...@p10g2000cwp.googlegroups.com:
>
> > rarely assembler
>
> In your case, sure.
>
I could reply that you're incoherent in several languages, including
assembler. But that would be unecessarily rude. Instead, I'll ask you
what your point is, or are you just postng witticisms to fill up an
otherwise boring afternonn?
--
Regards
Alex McDonald
Betov
@u72g2000cwu.googlegroups.com:
> [... Pathetic bullshits... ]
Confusing Methods and Language will never help
you at understanding anything. Mind you, the
day Assembly will not allow a programmer to do
something, no HLL will ever do this something
either.
Betov.
Dragontamer
You are welcome to an opinion.
But regardless; could you explain to me (don't even need to program or
show code) how you'd
implement the following functional methods in assembly language
(without resorting
to using or creating an external scripting language of some sort,
because you'd just
be creating another language to fill the holes that Assembly cannot do
by itself):
1. First order Functions; aka, functions as data.
2. Defining functions as combinations of data
3. Currying
4. Lazy data structures (such as an infinitly long list)
5. Guarentee a lack of side effects in a specific function
6. Creating a function during runtime
Mind you; i remember Randall writing how to pass data by lazy
evaluation in his
"Art of Assembly" book. So if Randall can come up with number 4, i'm
sure you can as
well :-p
Now; to disprove your statement; all 6 of those exist in Haskell, thus
it is something
Haskell (a very HLL) can do, that assembly cannot do.
1. Haskell basically only deals with functions. All data is concieved
as a function
that only returns one value.
2. The foldr example in my last post was Haskell code.
3. Again, the concept in my last post was a currying example in
Haskell.
4. fibs = 1 : 1 : zipWith (+) fibs (tail fibs)
Again, haskell. Scheme also provides a way for lazy evaluation wit
"delay" and "force"
5. Well, more of a feature of Haskell and not really anything you can
do in assembly.
Haskell guarentees a lack of side-effects for the majority of the
functions you define,
allowing the programmer to know that the function will always work the
same regardless.
So I cheated by including this one :) knowing Assembly simply cannot
guarentee this.
(else, it wouldn't be assembly, would it). But with that said, it is a
programming method
that Haskell supports that Assembly doesn't.
Now, to stop confusion: Haskell allows side effects through control
structures called
"Monads". So yes, you can create a pseudo random generator.
6. Haskell can do this with lambda function. Ditto with Scheme and
Lisp, and python.
It *defines* a new function; during runtime. So you can read in a file
for example, and
create a new function based on the file's inputs, or the user's input,
or data from
a network.
Again, explain how to do these in Assembly without creating another
(scripting) language
for support. The only way I (personally) can think of doing these in
Assembly is by
writing a simplified Haskell interpreter and embedding it into assembly
:-p
(well, enough of an interpreter to support runtime "lambda" statements,
and represent
functions during runtime)
Now seriously: I don't think you could learn *any* core concept of
"functional programming"
(the term used to describe programming using lazy evaluation, runtime
functions,
generators, lambda etc. etc.) in assembly language.
Actually, again, i remember Randall talking about how to do Lazy Eval
in Assembly, so
hope is not lost :-p So i change my stance to *most* concpets of
functional programming
can't be done in assembly.
--Dragontamer
\~o/~///annabee
Shut the fuck up !
:)))
\~o/~///annabee
Alex McDonald//
Regards. :))
\~o/~///annabee
assembler. But that would be unecessarily rude. Instead, I'll ask you
what your point is, or are you just postng witticisms to fill up an
otherwise boring afternonn?
--
Regards
Alex McDonald //
Lets start morsing to the computer. How fast can you type ?
Betov
@u72g2000cwu.googlegroups.com:
> [... nothing...]
Why don't you go and learn a bit of Assembly, instead
of saying stupidities?
Or... nothing at T.V.?
Betov.
Dragontamer
Betov wrote:
> "Dragontamer" <prti...@gmail.com> écrivait news:1140816233.718574.100770
> @u72g2000cwu.googlegroups.com:
>
> > [... nothing...]
>
> Why don't you go and learn a bit of Assembly, instead
> of saying stupidities?
>
> Or... nothing at T.V.?
Glad to know you are stumpped by my beginner questions
--Dragontamer