I'm not talking about client computers. My development is done for server side applications deployed on a clustered Sparc environment. Speed isn't a factor.


And you must have missed this internal memo originated from Sun. You might argue that the problem is the implementaion of JVM and the language itself is fine (as many Java coders do and I totally agree). Then, again, if Java wants to compete with other HLL (let alone machine languages), the implementation should be straightened up.

Funny, even Sun themselves could not make it right, but they require others some serious test (I forgot the name of the test. TCx?)

BTW, if speed is not a problem at all, then you don't need assembly language at all.

Anyhow, Sparc has a very different machine language than x86 (did you notice?), and Windows does not run on Sparc. AFAIK, non-x86 Win32 architectures are PPC, Alpha, and MIPS. (Yes, not 64. 32.) What are you doing in Win32ASM forum when none of your platform and your development language matches any of the topics we discus here? You'd better hang out at Sun's site. I'll see you there. :)
Posted on 2003-03-03 22:42:46 by Starless
well, speed seems to be an issue for server-side computers as well... many companies tout their program as being able to handle more users /w less system resources, able to process more queries/second, etc. Even M$'s budget doesn't allow for gross waste on hardware (not to mention nobody would want to run their software if it only ran well on extremely expensive hardware).
Posted on 2003-03-03 22:57:42 by jademtech



IMO, it's portability is worth the speed. It's not like it was 5 years ago, with 3ghz CPUs the speed of Java has gotten much better.

What does it mean?

Sure.. if we keep yesterday's computing needs with today's CPUs then Java is fine, a bit like to say "nobody will ever need more than 100 MIPS"..

..but what about moving on with times?

Run yesterday's software on today's computers: do it in Java or VisualBasic
Run today's software on today's computers: do it in C or C++
Run tomorrow's software on today's computers: do it in Assembly

That's how I like to see it..

PS: I see you're from Richmond.. hey, you ain't Bill under covert action, are you? :grin:
Posted on 2003-03-04 03:31:32 by Maverick
I use asm artistically
You mean you program artistically or create artistic programs?
When I have the time I like to write beautiful code.
MS Office XP is such a sluggish bunch of pig programs.
Over the last weekend I was forced to convert to XP because my stock software is switching over and won't support anything else. First thing I noticed was XP was slower even after turning off most of the visual enhancements (I'm running 1.7ghz P4).

I used to design hardware so asm just made more sense because I could follow what it was doing in the hardware. There were/are times when I read a book about HLLs and I can't figure what the heck they're talking about.
Posted on 2003-03-04 09:30:54 by drhowarddrfine
I think that's because most HLLs are understood by nobody except their creators.

Look at C++: it has such a plethora of things and such a vast array of options that nobody sees how it works. I think Soustrup and maybe 3 or 4 other people understand c++ fully. I know I certainly don't.

That's where they lost it. When the talk about your program shifts from the design of your program to "I have no clue how to do this well/correctly in language xxxx" then something is fundamentally wrong with language xxx. HLL languages seem to suffer a lot from it, the more abstract they get, the more the programmer seems to have to deal with the language itself and the less time he has left for the design of the program, which is ironically the exact opposite of the initial goal of abstract languages like c++ :|

Another problem is also the fact that people try to abstract everything instead of only where it makes sense. You end up with hundreds of classes and blackboxes, the programmer in the middle and the program and its design behind the virtual trees blocking his vision. There's not enough knowledge thought. I know my prof stating "goto is bad" nobody asked why and he didn't explain why. I knew that he meant that you could cross logical/scope boundaries and hence mess up the workings of your program but I bet you that the other students where pretty much cluelessly accepting it as a silent axiom.
Posted on 2003-03-04 10:03:44 by Hiroshimator
little do they know that:

for, elseif, else, while, break, case ... includes "gotos" in disguise... :grin:

"The Natural Way To Draw" by Kimon Nicolaides has a great explanation of art.... that can be applied even in programming. :grin:
Posted on 2003-03-04 10:50:17 by arkane

There were/are times when I read a book about HLLs and I can't figure what the heck they're talking about.

:)
The same here.
I would say that I use ASM 'cause I'm too stupid for HLL.
Sometimes I even too stupid for ASM at the times I write in HEX or binary :)
Posted on 2003-03-04 11:25:46 by The Svin

Run yesterday's software on today's computers: do it in Java or VisualBasic
Run today's software on today's computers: do it in C or C++
Run tomorrow's software on today's computers: do it in Assembly

That's how I like to see it..


Good point. :)


PS: I see you're from Richmond.. hey, you ain't Bill under covert action, are you? :grin:


Who? :confused:
Posted on 2003-03-04 12:06:33 by CompiledMonkey
I would say that I use ASM 'cause I'm too stupid for HLL.
If The Svin says that then all is right in my little world.:alright:
Posted on 2003-03-04 13:52:21 by drhowarddrfine

I would say that I use ASM 'cause I'm too stupid for HLL.


I thought it would be the other way around. :confused:
Posted on 2003-03-04 13:57:08 by CompiledMonkey
Speaking of little worlds, maybe i'm in my own little world as well...but anyhow, I think the better question is:

Why not ASM?

If you think in those terms, and evalute your solution's needs, the need (or lack thereof) is far more apparent. Digressing a little, heres a odd analogy (maybe its silly but hey!):

Java/.NET and comparable languages (EHLL's - Extremely High Level Languages... also known as HELL's) are similiar to a bike with training wheels. There are extremely easy to use (almost anyone can learn), using abstract concepts (turn left, turn right, go forward, etc), removing the programmer from endangering himself (he doesn't have to worry about the bicycle falling over). Of course they aren't completely fool proof, as a catastropic mistake (like driving the bicycle off a cliff) will still result in major injury.

C/C++ and more standardly used HLL's are like above with training wheels removed. You certainly have more concerns (you have to worry about falling over now), but you still don't have to understand the fine grained concepts (like the physics behind the motion), and you have a few less restrictions as to what you can do (go fast, slow, change gears, tricks...etc). This bicycle almost appeals more to the greater public, since most people wouldn't want to be seen riding around with training wheels anyway...

Now ASM is like not having a bicycle... just the parts to build one. Now you have to know not only how to ride it, but assemble (no pun intended) it as well. Its a dangerous process if you don't know what your doing (along with all the other concerns, now the bicycle can fall apart too, resulting in major injuries), but if you know how to make the parts work together, the result can be far greater than the above examples. Whats more, as you gain more and more knowledge, you might find that some of the parts aren't needed, and are actually slowing you down. However, since your building a custom solution by hand, its not something that is easily mass produced/usable.

Of course, maybe i'm not one to talk since I'm really an ASM newbie... but when i'm not required to write in one of those "other" languages, or when I want to actually challenge my mind a little, I truly enjoy ASM.

... (upon futher reflection, this post really is silly :tongue: )

-----
Domain
Posted on 2003-03-04 14:31:43 by Domain
Nice analogy:) . When you learn how to create the bike you can apply the knowledge to create something else or repair it when there are problems with it.
Posted on 2003-03-04 14:54:00 by Odyssey

You mean you program artistically or create artistic programs?
When I have the time I like to write beautiful code.

Over the last weekend I was forced to convert to XP because my stock software is switching over and won't support anything else. First thing I noticed was XP was slower even after turning off most of the visual enhancements (I'm running 1.7ghz P4).
I like to do both - artistic code and pretty programs.

I've used all versions of office from '95 and I must say XP is the biggest slowdown, yet. The 2003 version is suppose to be mostly rewritten for the XML integration and I hope this has removed some of the bloat - no doubt I will be disappointed once again. I am always at odds with the new features until I am forced to use another version for a while - then I know what I don't want to or can't do without.


I think that's because most HLLs are understood by nobody except their creators.
This seems to be the case with all abstractions - macros are the same way. Some macros in MASM I would never want to do without - having gotten use to seeing the code this way. But the uninitiated always seems to ask, "Is this MASM syntax?" :) Another appeal to ASM is the brief code - small quanta to be easily digested by anyone.
Posted on 2003-03-04 19:44:47 by bitRAKE
If you're doing stuff on the server side, I think performance is critical. It's no longer about 1 user, it's tens or hundreds or even thousands of users. Yea, I know, you're in a "clustered environment" so you say just throw more hardware at it.

However, there is another answer. What if you can do the same amount of work in less time? What if you can get a task done 5 or 10 or 20% faster, and free up a "slot" for another transaction that much quicker? What if you could do 6 transactions in the amount of time it takes to do 5? In other words, what if you can do the same work on 5 CPUs instead of 6? Why buy another processor when you're not using what you have to it's full potential?

I guess I'm spoiled. Hardware is cheap these days. I'm an old mainframe assembly guy, learned System/360 asm in 1971. Back then hardware was far from cheap. Computer "time" was expensive. Resources were scarse, small systems like the model 30 only had 64K main memory. Even the top of the line, multi-million dollar model 65 only had 1024K, or 1 meg, when it first came out. Some of the early disk drives (2311) were only 7 meg, and the "newer" 2314 were 28 meg. A bank of 8 2314 drives gave you a little over 200 meg. Not bad for a box about 6 feet tall, 3 feet wide, and about 18 feet long, with the attached control unit. :)

Anyway, I was born in a CICS type evironment. CICS was one of the first "server" applications (and it's still used on virtually every new IBM mainframe sold today). It's the program that talks to all those green terminals that you see in places like banks, airlines, insurance companies, the IRS, etc. A single large mainframe can talk to thousands of terminals "at the same time".

We've always had various HLLs on the maniframe, COBOL, PL/1, RPG, even C has been around for years now. COBOL (and other language) programmers can talk to CICS, using a special pre processor "language". You still see tons of want ads for CICS/COBOL programmers today. Now you know what it is, a COBOL programmer that also knows the "special language" needed to talk to terminals.

The point of this mess is, that even today on IBM's latest CMOS based, fibre optic channel, super wide word, Sysplex machines, I can almost always tell if a CICS program is written in Cobol or Assembly, just by the "feel" of the terminal response. It's not so much Cobol's fault, as it is the way Cobol programmers tend to think. Many don't use things like COMP or COMP-3, they just define a numeric field as the default "PIC 999" and let the compiler do the work. The problem is that this causes the compiler to generate huge amounts of code, PACKing and UNPKing or EDing, maybe CVBing and CVDing the data, every time you touch it. Along with the normal Cobol overhead, object code gets pretty big, taking longer to load, let alone execute (time slices can get pretty small with a few thousand users), and the larger size screws up the program cache along the way. :)

There are exceptions. A few Cobol programmers do use COMP and COMP-3, and they know the other optimization tricks. But most don't bother to dig that far down. Most aren't tech heads, they're business oriented coders that just want to get a job done. After all, that is who the language is aimed at.

If they were geeks, they would have written it in assembly language. And I think that's just as true for the Win32 environment as it is the S/390. Well, maybe not, I do have 32 years worth of "library" on the big box, including a couple of "home grown" MACRO based (assembly) "full languages" that I'm sure you've never heard of, but are still in use today, at least one 27 years after I first worked on it. Whoda thunk it, that old MVC instruction that I wrote back then ran several thousand times today... :grin:
Posted on 2003-03-04 21:44:52 by S/390
Good post S/390. :alright:
Posted on 2003-03-04 21:54:47 by CompiledMonkey
...and when I was your age we used to walk ten miles to school in ten feet of snow with just tennis shoes if we had shoes at all!:grin:
Posted on 2003-03-05 00:06:35 by drhowarddrfine

Hi S/390,
it's always fascinating and interesting to read your posts. :alright:
Posted on 2003-03-05 02:58:52 by Maverick

...and when I was your age we used to walk ten miles to school in ten feet of snow with just tennis shoes if we had shoes at all!:grin:

... up the hill both ways? :grin:

Sorry, I couldn't help it. Your post reminds me of Bill Cosby's show I saw on PBS. :grin:
Posted on 2003-03-05 06:00:20 by Starless

This seems to be the case with all abstractions - macros are the same way. Some macros in MASM I would never want to do without - having gotten use to seeing the code this way. But the uninitiated always seems to ask, "Is this MASM syntax?" :) Another appeal to ASM is the brief code - small quanta to be easily digested by anyone.


yes, but the difference is: for the macros the use is clear. Whenever people have an issue with a HLL then it's almost 90% about the use of a certain feature of the language. c++ has whole magazines staying alive to explain the use of core concepts of the language, so IMO it certainly is an issue.
Posted on 2003-03-05 06:02:40 by Hiroshimator
with 3ghz CPUs the speed of Java has gotten much better.
Java on CRAY
Posted on 2003-03-09 13:12:17 by drhowarddrfine