Should I learn Assembly?

[LakatosIstvan]

What I would really like to do is to be able to write programs in pure hexadecimal. You know, go REALLY old-school. How would you recommend doing this on a x86 processor?

[lulzfish]

What I would really like to do is to be able to write programs in pure hexadecimal. You know, go REALLY old-school. How would you recommend doing this on a x86 processor?

1. Get a hex editor
2. Learn the executable format for whatever OS you're using, I believe Linux prefers ELF
3. Write a "hello world" in assembly
4. Find a table of x86 opcodes to translate the assembly into machine code

Spoiler:

5. Throw all that shit in the garbage
6. Put your assembly program in a text file and send it to an assembler program that knows what the fuck it's doing
7. What the hell is wrong with you?
http://www.penny-arcade.com/comic/2002/5/20/

I dunno, that's REALLY old-school.
You might start by just assembling a simple program and then running it through a debugger and reading it in the hex editor to try to understand how it fits together.

[Earlz]

0xF4 right there! (0xF4=HLT. I only know that because when I was writing an x86 emulator it was a debugging symbol so I had to learn how to inject it straight into memory eventually.. )

I think knowing a few opcodes is handy..(really they follow a sort of pattern that can be memorized without a huge amount of effort, or at least the actual opcode, not all the Mod R/M crap and Groups and all of that other stuff that is annoying)

I once tried to write an OS in hex because I read a thing about how a guy wrote in hex(back in the day) extremely well. Like he used so much self modifying code because when you write in hex, there is no abstraction between code and data, and every opcode is a constant... It's very complicated to write anything non-trivial using self modifying hex though and I strongly o not recommend it for anything but laughs and giggles

[EduardoLeon]

This is what happens when you program in high-level languages too much before learning a REAL programming language:
http://stackoverflow.com/questions/1654425/how-do-i-convince-a-peer-that-algorithms-are-important

[You, sir, name?]

This is what happens when you program in high-level languages too much before learning a REAL programming language:
http://stackoverflow.com/questions/1654425/how-do-i-convince-a-peer-that-algorithms-are-important

People put way too much faith in time complexity. I've seen people rewrite an algorithm that looked like this

Code: Select all

for(int i = 0; i < I; i++)
  for(int j = 0; j < J; j++)
    do_something(i, j);


as

Code: Select all

for(int n = 0; n < I*J; n)
    do_something(n/J, n%J);


Because they figured the second algorithm was O(N) but the first one was O(N^2).

[EduardoLeon]

The first algorithm is NOOOOOOOOT O(n²). It's O(i*j).

[You, sir, name?]

The first algorithm is NOOOOOOOOT O(n²). It's O(i*j).

Of course it is. And so is the second one. And that is the point: Certain people think that as long as they can re-write the thing within the big-O as small as possible, the algorithm will somehow run faster. In this case, the first algorithm probably runs faster than the second one, since you have to do slow division and modulo operations at every iteration.

The blind time complexity cult is evil. An alarming amount of people are either oblivious to how it even works, or oblivious to when it is relevant. Though in the case with your link, it's more of a general premature optimization problem.

[Xanthir]

The first algorithm is NOOOOOOOOT O(n²). It's O(i*j).

That depends on whether the i and j are usefully distinct numbers. If so, then O(i*j) is right. If not, then O(n^2) is correct. Without context, you definitely can't use more than 3 Os in your NOOOOOOOOT.

[jroelofs]

If you're going to be programming in C or C++, learning assembly has another benefit. This may be different on Windows, but all too often I find that gdb does a terrible job at working out the value of a critical variable(this may be gcc's fault, not gdb's). When that happens, the only recourse is often to look at the disassembly and work it out from that.

Have you ever had that happen when you've compiled with "gcc -O0 -g"? I've really only seen gdb bug out over optimized code, usually when multiple variables get assigned to the same register and you are looking for something that isn't really there anymore.

[EduardoLeon]

The first algorithm is NOOOOOOOOT O(n²). It's O(i*j).

That depends on whether the i and j are usefully distinct numbers. If so, then O(i*j) is right. If not, then O(n^2) is correct. Without context, you definitely can't use more than 3 Os in your NOOOOOOOOT.

If j is O(f(i)), then n is O(i*f(i)), and the whole algorithm, being O(i*f(i)), would also be O(n).

[Rysto]

Have you ever had that happen when you've compiled with "gcc -O0 -g"? I've really only seen gdb bug out over optimized code, usually when multiple variables get assigned to the same register and you are looking for something that isn't really there anymore.

My company never tests with optimization turned off. There's very little point in testing code that will never be shipped to a customer.

[You, sir, name?]

The first algorithm is NOOOOOOOOT O(n²). It's O(i*j).

That depends on whether the i and j are usefully distinct numbers. If so, then O(i*j) is right. If not, then O(n^2) is correct. Without context, you definitely can't use more than 3 Os in your NOOOOOOOOT.

If j is O(f(i)), then n is O(i*f(i)), and the whole algorithm, being O(i*f(i)), would also be O(n).

In this case, it was something like I \propto J
For the first algorithm, it is O(n_1^2), where n_1 \propto I
For the second algorithm, it is O(n_2), where n_2 \propto IJ, or equivalently O(n_1^2)

[EduardoLeon]

Yes, but n1 and n2 are not the same thing.

[You, sir, name?]

Yes, but n1 and n2 are not the same thing.

That's exactly the point. But people who do not understand time complexity will not see that distinction. They see "Yay, I found an O(n) algorithm! Now my program will run faster!"

[EduardoLeon]

Yes, but n1 and n2 are not the same thing.

That's exactly the point. But people who do not understand time complexity will not see that distinction. They see "Yay, I found an O(n) algorithm! Now my program will run faster!"

I didn't think you underestimated people that much.

[Rysto]

Yes, but n1 and n2 are not the same thing.

That's exactly the point. But people who do not understand time complexity will not see that distinction. They see "Yay, I found an O(n) algorithm! Now my program will run faster!"

So basically, people who don't understand what they're doing write crappy programs? Now there's a revelation.

Time complexity isn't the issue here.

[cerbie]

This is what happens when you program in high-level languages too much before learning a REAL programming language:
http://stackoverflow.com/questions/1654425/how-do-i-convince-a-peer-that-algorithms-are-important

I only recently tried messing with assembly thanks to availability of basic MIPS simulators/emulators (I'd like to really mess around w/ AVR and ARM), and almost always am dealing with ASP (as in VB6), Lua, PHP, Python, or BASH...and I don't get it. The second snippet is far easier to understand, but chances are they that they will both do the same things as well (if they are equivalent), unless you have the binary the compiler made out of it to prove otherwise (and then, it may be close enough that an actual test may be needed).

I really don't think, "real languages," has jack shit to do with it. If you can understand your problem, and how your solution works, you should be able to think about it at multiple levels of abstraction, and walk through what it's doing. Then you code it. Then, you may or may not have to repeat some steps.

OTOH, I eat quiche and like merge sort.

[EduardoLeon]

I really don't think, "real languages," has jack shit to do with it. If you can understand your problem, and how your solution works, you should be able to think about it at multiple levels of abstraction, and walk through what it's doing. Then you code it. Then, you may or may not have to repeat some steps.

If you can't distinguish between atomic instructions and library function calls, which often happens when you use toy languages, then you're being encouraged to write potentially inefficient programs.

OTOH, I eat quiche and like merge sort.

My ideal sort algorithm for arrays is the following:

1. Split the array into n pieces, where n is the number of processors.
2. Order each piece using heapsort.
3. Merge.

[cerbie]

I really don't think, "real languages," has jack shit to do with it. If you can understand your problem, and how your solution works, you should be able to think about it at multiple levels of abstraction, and walk through what it's doing. Then you code it. Then, you may or may not have to repeat some steps.

If you can't distinguish between atomic instructions and library function calls, which often happens when you use toy languages, then you're being encouraged to write potentially inefficient programs.

1. What is a toy language? From your posts that have the word, "toy," in them, the only kind of language that isn't appears to be assembly, and I don't know of any assembly language that has libraries to call.
2. "If you can't distinguish between atomic instructions and library function calls": I have no Earthly idea what you're trying to say, here. Both instructions and library function calls may be atomic or not atomic. If you don't know you're using a library, how do you to even type the name of the library and function name, or just function name, into your text editor, give it the proper parameters, have it compile, and have it give you the results you wanted?

[littlebuddy]

oh gawd i had the best time learning assembly. i used professional assembly language by blum and it was fantastic; bit of a bible thumper though. definitely do it, you won't be sorry.

[EduardoLeon]

oh gawd i had the best time learning assembly. i used professional assembly language by blum and it was fantastic; bit of a bible thumper though. definitely do it, you won't be sorry.

YEAH!!1one USING ASSEMBLAH IS TEH SHIT!!!111ONE

Now, really, x86 machine code and assembler are such awesome (non-)languages!

1. What is a toy language? From your posts that have the word, "toy," in them, the only kind of language that isn't appears to be assembly, and I don't know of any assembly language that has libraries to call.

Actually, I statically link my object files to the OS-specific library that contains the function that dynamically calls what in Windows would be called DLLs. Isn't it awesome?

2. "If you can't distinguish between atomic instructions and library function calls": I have no Earthly idea what you're trying to say, here. Both instructions and library function calls may be atomic or not atomic. If you don't know you're using a library, how do you to even type the name of the library and function name, or just function name, into your text editor, give it the proper parameters, have it compile, and have it give you the results you wanted?

If you have a library function that implements a O(f(n)) algorithm, and then a program function that calls the library function O(g(n)) times, you can't expect the program function's algorithm to be O(g(n)) unless f(n) is constant. If O(g(f(n))) seems like too much for you, then consider another algorithm. In ordinary words, that means that you shouldn't call a complex library function so much.

My thesis is that these ideas can be more easily learnt if you program in assembly. Other languages reward you so much for hacking a solution that "does the job, period."

If, again, I am not clear, excuse me. English is not my first language.

[lulzfish]

So what you're saying is that assembly is good for learning because there's no way to just call a library and re-use their code?
I think there is, but I don't know any assembly, so I'm actually not sure.

[EduardoLeon]

So what you're saying is that assembly is good for learning because there's no way to just call a library and re-use their code?
I think there is, but I don't know any assembly, so I'm actually not sure.

You CAN call a library. But you have to do more complicated stuff to achieve that.

[cerbie]

1. What is a toy language? From your posts that have the word, "toy," in them, the only kind of language that isn't appears to be assembly, and I don't know of any assembly language that has libraries to call.

Actually, I statically link my object files to the OS-specific library that contains the function that dynamically calls what in Windows would be called DLLs. Isn't it awesome?

Not really. It's generally a build script or compiler option to make the code a bit faster loading and/or larger and/or more fragile. Even so, you're still calling a library. All you've done there, 99% of the time, is made it a bit easier for the compiler to do certain optimizations that it can't do with your program and the library as separate binaries. You're still calling a library function, and incurring all the overhead of the actual operations the library is doing.

Still: what makes a language a toy language?

2. "If you can't distinguish between atomic instructions and library function calls": I have no Earthly idea what you're trying to say, here. Both instructions and library function calls may be atomic or not atomic. If you don't know you're using a library, how do you to even type the name of the library and function name, or just function name, into your text editor, give it the proper parameters, have it compile, and have it give you the results you wanted?

If you have a library function that implements a O(f(n)) algorithm, and then a program function that calls the library function O(g(n)) times, you can't expect the program function's algorithm to be O(g(n)) unless f(n) is constant. If O(g(f(n))) seems like too much for you, then consider another algorithm. In ordinary words, that means that you shouldn't call a complex library function so much.

True, but unless you're using VB (I'll happily code VB6/VBA/ASP again, but I'll badmouth it all the way to the bank, too), your problem should come first. Then you decide how to take care of it based on your needs. Sometimes those needs do include giving up time or memory simplicity or efficiency so that someone else can easily work on your code, as the customer finds out they didn't like the requirements they thought they wanted. You are very expensive, compared to new servers, and workstation upgrades. O(f(g(n)) sounds great, if it works well for the problem, and makes for easy to work on code (depending on actual performance of f and g!). When and if it is too slow, go back and fix it up nicer. You don't have a problem until you code it thinking that it will be fast when n is large, and you also allow for large n--after all, O(f(g(n)) might be faster than an equivalent O(1), for small n.

OTOH, if you are worried about specific timing, then making something known fast, regardless of input size, is important, and is what makes you worth your pay. In that case, spending extra time on more complicated code that you can guarantee to be a bit faster makes a great deal of sense (realtime A/V in userspace, FI).

On my bloody Halloween prop hand, though, even in high level languages, you can do things that are scary, just like in lower-level ones. CakePHP comes to mind. After about 15 minutes looking over some the code, I got frightened, and hope to never use it. The problem is not anything to do with understanding that moves, jumps, and xors (xor is like the computer's e--simple, hard to learn to use, but mindbogglingly versatile) are going on underneath (you're at least three levels removed from that), but not understanding the nature of the problem(s) presented.

My thesis is that these ideas can be more easily learnt if you program in assembly. Other languages reward you so much for hacking a solution that "does the job, period."

My thesis is that having an intuitive understanding of a problem makes it easier to solve than trying to hack together a solution. f(X,Y,Z) -> { Q,W,E, {R,T} } is not something bound by programming language. However, if, "let's make the SQL DB OO, with no natural info, then wrap a memoizing lazy XML queue around standard <imperative language> built-in functions, and it will save us time and make it work really fast," I have a feeling that learning assembly will not save you. You need to know your problem, know your solution to said problem (or admit that you don't, and work from there), and know your tools (or admit that you don't, and learn).

[EduardoLeon]

Still: what makes a language a toy language?

The fact you don't need to understand how the computer computes your programs.

Sometimes those needs do include giving up time or memory simplicity or efficiency so that someone else can easily work on your code, as the customer finds out they didn't like the requirements they thought they wanted. You are very expensive, compared to new servers, and workstation upgrades.

I am often told to make my programs as fast as possible. And I am not very expensive, my salary is meagre.

On my bloody Halloween prop hand, though, even in high level languages, you can do things that are scary, just like in lower-level ones. CakePHP comes to mind. After about 15 minutes looking over some the code, I got frightened, and hope to never use it.

What can be so complicated about web application frameworks? It can be long, poorly engineered and implemented, but it cannot be complicated. In fact, nothing is actually complicated, unless you are designing heuristics to solve NP-hard problems.

However, if, "let's make the SQL DB OO, with no natural info, then wrap a memoizing lazy XML queue around standard <imperative language> built-in functions, and it will save us time and make it work really fast," I have a feeling that learning assembly will not save you.

The question was not whether assembly is the universal solution, nor my arguments were suggesting that.

[cerbie]

Still: what makes a language a toy language?

The fact you don't need to understand how the computer computes your programs.

Disregarding that modern fat CPUs don't even force you to know that...much of what makes something a, "toy," can be quite the feature. You can run, and get the same results, from something on a ARM, Alpha, x86_64, IA64, or whatever else, without writing that code again for it. As long as any performance hit in changing is minor, and does not hurt possible scaling out, it's generally considered better than a tweaked solution based on udnerstanding how one platform's inner workings do their thing.

Sometimes those needs do include giving up time or memory simplicity or efficiency so that someone else can easily work on your code, as the customer finds out they didn't like the requirements they thought they wanted. You are very expensive, compared to new servers, and workstation upgrades.

I am often told to make my programs as fast as possible. And I am not very expensive, my salary is meagre.

A meager salary is generally reality. For many of us, we aren't told to make our code run as fast as possible, but to get the work done as fast as possible (within reason), and as easy to work on as possible--customers have a habit of not knowing what they want, and then not saying what they actually want when they do know it . If time to service a request is a real problem, then hardware being cheap or expensive doesn't matter.

On my bloody Halloween prop hand, though, even in high level languages, you can do things that are scary, just like in lower-level ones. CakePHP comes to mind. After about 15 minutes looking over some the code, I got frightened, and hope to never use it.

What can be so complicated about web application frameworks? It can be long, poorly engineered and implemented, but it cannot be complicated. In fact, nothing is actually complicated, unless you are designing heuristics to solve NP-hard problems.

In the sense of mathematically looking at the problem, no. The problem ends up fairly simple. It's that there is some idea that everything must be done, everything must be integrated, and if what appears an ideal processing or data model isn't well supported, it could be hammered into place, anyway, rather than using the strengths of the supported tools. Also, it seems that there is a plague of people who think IO is free, or is a negligible bottleneck.

However, if, "let's make the SQL DB OO, with no natural info, then wrap a memoizing lazy XML queue around standard <imperative language> built-in functions, and it will save us time and make it work really fast," I have a feeling that learning assembly will not save you.

The question was not whether assembly is the universal solution, nor my arguments were suggesting that.

Nor I that you were saying it was. Rather, that knowing some assembly is so far disconnected from many kinds of programming issues, which are very high level, that it won't help. That it is mental laziness, and/or misplaced goals, that makes the slowness and the bloat, rather than insulation from the machine code. However, I would certainly hope that the guys implementing the <imperative language>, networking, and the DB engine, could bootstrap a few computer architectures .

[EduardoLeon]

As long as any performance hit in changing is minor, and does not hurt possible scaling out, it's generally considered better than a tweaked solution based on udnerstanding how one platform's inner workings do their thing.

It depends on how much you think "minor" should be.

If time to service a request is a real problem, then hardware being cheap or expensive doesn't matter.

I can smell Ruby fanboyism in the air. It smells like the nuts of someone who hasn't had a shower. (On a second thought, I realized I should be more polite.) Really? That's not what the customer I'm working for says.

Also, it seems that there is a plague of people who think IO is free, or is a negligible bottleneck.

IO is obviously a major bottleneck, taking in consideration the relative speed of peripherals compared to processors and RAM memories. The solution is to perform other tasks while one specific task is "stuck" with IO. This is why a Real Programmer must grok threads and parallelism in general. And, no, the OS takes care of that is not a valid answer.

That it is mental laziness, and/or misplaced goals, that makes the slowness and the bloat, rather than insulation from the machine code.

Assembly is the best way to get rid of mental laziness.

[Earlz]

As long as any performance hit in changing is minor, and does not hurt possible scaling out, it's generally considered better than a tweaked solution based on udnerstanding how one platform's inner workings do their thing.

It depends on how much you think "minor" should be.

If time to service a request is a real problem, then hardware being cheap or expensive doesn't matter.

I can smell Ruby fanboyism in the air. It smells like the nuts of someone who hasn't had a shower. (On a second thought, I realized I should be more polite.) Really? That's not what the customer I'm working for says.

Also, it seems that there is a plague of people who think IO is free, or is a negligible bottleneck.

IO is obviously a major bottleneck, taking in consideration the relative speed of peripherals compared to processors and RAM memories. The solution is to perform other tasks while one specific task is "stuck" with IO. This is why a Real Programmer must grok threads and parallelism in general. And, no, the OS takes care of that is not a valid answer.

That it is mental laziness, and/or misplaced goals, that makes the slowness and the bloat, rather than insulation from the machine code.

Assembly is the best way to get rid of mental laziness.

Ruby fanboyism? I'm a fan of Ruby and I like low level programming, whats bad about Ruby? It's an interpreted language, as such it's slower than a (most) compiled language. It's beautiful to code in, but I wouldn't say you should put it in time critical applications, or that you should use it alone(It's apparently easy to extend with C)

Assembly is not the best way to get rid of mental laziness, it's just a way to focus on something else than the real problem.
So while your replacing

Code: Select all

mov eax,0


with

Code: Select all

xor eax,eax


I'll be programming on a *real* problem.

[LakatosIstvan]

As long as any performance hit in changing is minor, and does not hurt possible scaling out, it's generally considered better than a tweaked solution based on udnerstanding how one platform's inner workings do their thing.

It depends on how much you think "minor" should be.

If time to service a request is a real problem, then hardware being cheap or expensive doesn't matter.

I can smell Ruby fanboyism in the air. It smells like the nuts of someone who hasn't had a shower. (On a second thought, I realized I should be more polite.) Really? That's not what the customer I'm working for says.

Also, it seems that there is a plague of people who think IO is free, or is a negligible bottleneck.

IO is obviously a major bottleneck, taking in consideration the relative speed of peripherals compared to processors and RAM memories. The solution is to perform other tasks while one specific task is "stuck" with IO. This is why a Real Programmer must grok threads and parallelism in general. And, no, the OS takes care of that is not a valid answer.

That it is mental laziness, and/or misplaced goals, that makes the slowness and the bloat, rather than insulation from the machine code.

Assembly is the best way to get rid of mental laziness.

Ruby fanboyism? I'm a fan of Ruby and I like low level programming, whats bad about Ruby? It's an interpreted language, as such it's slower than a (most) compiled language. It's beautiful to code in, but I wouldn't say you should put it in time critical applications, or that you should use it alone(It's apparently easy to extend with C)

Assembly is not the best way to get rid of mental laziness, it's just a way to focus on something else than the real problem.
So while your replacing

Code: Select all

mov eax,0


with

Code: Select all

xor eax,eax


I'll be programming on a *real* problem.

Now that's just plain mean

It's nice to see what a controversial thread I've started. Who knows what terror I might unleash in the Religious Wars section.

Since we're talking about programming and how to get rid of mental laziness, I'd like to hear some of your opinion on lambda calculus, If learning to use it would turn into a benefit like assembly would?

[EduardoLeon]

Ruby fanboyism? I'm a fan of Ruby and I like low level programming, whats bad about Ruby? It's an interpreted language, as such it's slower than a (most) compiled language. It's beautiful to code in, but I wouldn't say you should put it in time critical applications, or that you should use it alone(It's apparently easy to extend with C)

Beautiful to code in? Why do I have to warp my mind around whether the if clause can be used before or after the conditionally-executed code? If the problem is the formal language vs. human language gap, I prefer those efforts aimed at making human languages formal, not vice versa.

Assembly is not the best way to get rid of mental laziness, it's just a way to focus on something else than the real problem.

So while your replacing (...) I'll be programming on a *real* problem.

If you have experience with assembler, you can do those mechanical tasks (like emptying registers using xor rather than mov) without doing any effort. It will come naturally, because you will think the way the computer works.

Now that's just plain mean

It's nice to see what a controversial thread I've started. Who knows what terror I might unleash in the Religious Wars section.

Actually, I like controversy. I don't mind the "mean" replies.

Since we're talking about programming and how to get rid of mental laziness, I'd like to hear some of your opinion on lambda calculus, If learning to use it would turn into a benefit like assembly would?

There are threads on that topic in the Religious Wars section.

[cerbie]

As long as any performance hit in changing is minor, and does not hurt possible scaling out, it's generally considered better than a tweaked solution based on udnerstanding how one platform's inner workings do their thing.

It depends on how much you think "minor" should be.

And that depends on computing/IO power available, and what needs doing. <march> assembly will let you do it faster than C, C will let you do it faster than Java, and currently, Java or Haskell will probably do whatever it is faster than anything else, ATM.

If time to service a request is a real problem, then hardware being cheap or expensive doesn't matter.

I can smell Ruby fanboyism in the air. It smells like the nuts of someone who hasn't had a shower. (On a second thought, I realized I should be more polite.)

Probably. I don't get what is supposed to be so great or special about it. I don't see why you think it's so bad, either, though. However, how did Ruby even come up? I generally don't think of Ruby when I think of high throughput and/or low latency.

Really? That's not what the customer I'm working for says.

So, your customer has an infinite budget and no deadlines?

Also, it seems that there is a plague of people who think IO is free, or is a negligible bottleneck.

IO is obviously a major bottleneck, taking in consideration the relative speed of peripherals compared to processors and RAM memories. The solution is to perform other tasks while one specific task is "stuck" with IO. This is why a Real Programmer must grok threads and parallelism in general.

I'm talking about cases like hundreds of HDD accesses (the OS+FS buffers, you know) or network transactions per second, when one or two would suffice, and also significantly reduce CPU/RAM time-wasting. I'm amazed that some of the things I've seen ever worked at all.

If you're putting an implicit POSIX in front of threads, I have yet to grok them, and have no intentions of trying. IMO, Java got threads right (and you won't find me saying much else friendly about Java).

And, no, the OS takes care of that is not a valid answer.

Well, that depends. If you can make generic flexible worker processes/threads, and don't rely on very fast responses from pipes, sockets, etc., the OS pretty much will do it for you (don't expect miracles from Windows, though, even then). The real trick is figuring out what you are doing that can take advantage it enough to be worth implementing it.

That it is mental laziness, and/or misplaced goals, that makes the slowness and the bloat, rather than insulation from the machine code.

Assembly is the best way to get rid of mental laziness.

It's a good way to never get anything high level done, too. For a crappy metaphor, it's lazy to cook with a microwave oven. It's not lazy to cook without worrying about how to craft the knife you are using.

[EduardoLeon]

Probably. I don't get what is supposed to be so great or special about it. I don't see why you think it's so bad, either, though. However, how did Ruby even come up? I generally don't think of Ruby when I think of high throughput and/or low latency.

Well, in my mind, Ruby programming is an insult. Perhaps if the language's maker(s) tried to make it a bit less human and a bit more strict, it wouldn't suffer from the horrible performance problems that make it so impossible to use for anything big. It's actually a shame, because the platforms made for it are rather nice.

So, your customer has an infinite budget and no deadlines?

Not actually. They force me to write fast programs using a limited budget, which means that I am cheap. (Perhaps if I worked as a whore I would make more money from my effort.) As for deadlines, well, there is not such a thing as a meaningful deadline here. Consultancy firms promise the impossible and customers don't engage in software development projects if consultancy firms only promise what is possible.

I'm talking about cases like hundreds of HDD accesses (the OS+FS buffers, you know) or network transactions per second, when one or two would suffice, and also significantly reduce CPU/RAM time-wasting. I'm amazed that some of the things I've seen ever worked at all.

If you are a decent assembly programmer, then you have a solid background to predict and deal with those situations, even if you're not using assembly. Programmers who have never been exposed to assembly usually have to wait until slow response times happen in the test phase.

If you're putting an implicit POSIX in front of threads, I have yet to grok them, and have no intentions of trying. IMO, Java got threads right (and you won't find me saying much else friendly about Java).

Why? Manually doing threads is awesome! It's particularly exciting in Windows, because its threading system is broken and you have to deal with that fact.

Well, that depends. If you can make generic flexible worker processes/threads, and don't rely on very fast responses from pipes, sockets, etc., the OS pretty much will do it for you (don't expect miracles from Windows, though, even then). The real trick is figuring out what you are doing that can take advantage it enough to be worth implementing it.

What a pity! Windows is omnipresent here. To make it worse, SQL Server is omnipresent here as well. Linux sysadmins and Oracle DBAs are particularly expensive.

Assembly is the best way to get rid of mental laziness.

It's a good way to never get anything high level done, too. For a crappy metaphor, it's lazy to cook with a microwave oven. It's not lazy to cook without worrying about how to craft the knife you are using.

Yes, it's a crappy metaphor.

[Earlz]

Probably. I don't get what is supposed to be so great or special about it. I don't see why you think it's so bad, either, though. However, how did Ruby even come up? I generally don't think of Ruby when I think of high throughput and/or low latency.

Well, in my mind, Ruby programming is an insult. Perhaps if the language's maker(s) tried to make it a bit less human and a bit more strict, it wouldn't suffer from the horrible performance problems that make it so impossible to use for anything big. It's actually a shame, because the platforms made for it are rather nice.

So, your customer has an infinite budget and no deadlines?

Not actually. They force me to write fast programs using a limited budget, which means that I am cheap. (Perhaps if I worked as a whore I would make more money from my effort.) As for deadlines, well, there is not such a thing as a meaningful deadline here. Consultancy firms promise the impossible and customers don't engage in software development projects if consultancy firms only promise what is possible.

I'm talking about cases like hundreds of HDD accesses (the OS+FS buffers, you know) or network transactions per second, when one or two would suffice, and also significantly reduce CPU/RAM time-wasting. I'm amazed that some of the things I've seen ever worked at all.

If you are a decent assembly programmer, then you have a solid background to predict and deal with those situations, even if you're not using assembly. Programmers who have never been exposed to assembly usually have to wait until slow response times happen in the test phase.

If you're putting an implicit POSIX in front of threads, I have yet to grok them, and have no intentions of trying. IMO, Java got threads right (and you won't find me saying much else friendly about Java).

Why? Manually doing threads is awesome! It's particularly exciting in Windows, because its threading system is broken and you have to deal with that fact.

Well, that depends. If you can make generic flexible worker processes/threads, and don't rely on very fast responses from pipes, sockets, etc., the OS pretty much will do it for you (don't expect miracles from Windows, though, even then). The real trick is figuring out what you are doing that can take advantage it enough to be worth implementing it.

What a pity! Windows is omnipresent here. To make it worse, SQL Server is omnipresent here as well. Linux sysadmins and Oracle DBAs are particularly expensive.

Assembly is the best way to get rid of mental laziness.

It's a good way to never get anything high level done, too. For a crappy metaphor, it's lazy to cook with a microwave oven. It's not lazy to cook without worrying about how to craft the knife you are using.

Yes, it's a crappy metaphor.

@ruby
A bit less human readable? Thats the entire point! A language that is natural to program in. The days of cryptic Fortran are long gone buddy and there is no sense in going to C-- (yes thats a real language) to get a tiny bit more control over your computer(at risk of breaking portability).
Have you ever stopped to think that the great platforms are great because of the language support? Or do you only see 1 side of every argument?

@deadlines
Most customers can handle if there page requests are 2ms slower, and would be willing to pay you the same amount(for half of your time. You could always implement an assembly CGI and it'll be damn fast, but really? What is the point?)

@threading
I like how Posix threads work. They seem like home to me... And I would much rather get a seg fault than the fun error of "This object can only be modified by the thread that created it" Come on C#, you can give the programmer a tiny bit more control can't you?

@IO
I don't think assembly will ever help with predicting which SQL queries run the fastest. Disk IO, maybe.. but still I don't think assembly really helps with understanding the latency of IO

@metaphor
I shouldn't have to understand how the silicon in an OR gate chip works and selectively conducts electricity in order to use an OR operation in a circuit, Nor should I concern myself with the exact mixture of doped silicon and whatever else goes into an OR gate.

[Hectamatatortron]

We JUST went over how Boron, Arsenic and Silicon mixtures can be used to make transistors in Computer Architecture.

Get out of my head, Earlz.

I agree you shouldn't need to know so much about things you're abstracting if the goal is to utilize the higher level for purposes of efficiency, but I also have to wonder how, at least in the case of technologies related to your field of study, you could ever not be compelled to act on the curiosity you assuredly have for how those lower level systems function.

Assembly is pretty much in the middle of it all and I've enjoyed learning both higher level languages and what comprises a computer since achieving fluency in assembly language. But I already said it should be learned to the topic creator, so I don't know where I'm going with this.

[You, sir, name?]

We JUST went over how Boron, Arsenic and Silicon mixtures can be used to make transistors in Computer Architecture.

Get out of my head, Earlz.

Boron? What an peculiar choice of dopant. I guess it ought to work, since it is in the right neighborhood of the periodic table, but still. Peculiar.

[cerbie]

Probably. I don't get what is supposed to be so great or special about it. I don't see why you think it's so bad, either, though. However, how did Ruby even come up? I generally don't think of Ruby when I think of high throughput and/or low latency.

Well, in my mind, Ruby programming is an insult. Perhaps if the language's maker(s) tried to make it a bit less human and a bit more strict, it wouldn't suffer from the horrible performance problems that make it so impossible to use for anything big. It's actually a shame, because the platforms made for it are rather nice.

*shrug* Maybe a follow-on will fix those things. The second mouse gets the cheese.

So, your customer has an infinite budget and no deadlines?

Not actually. They force me to write fast programs using a limited budget, which means that I am cheap. (Perhaps if I worked as a whore I would make more money from my effort.) As for deadlines, well, there is not such a thing as a meaningful deadline here. Consultancy firms promise the impossible and customers don't engage in software development projects if consultancy firms only promise what is possible.

My point is that TANSTAAFL. Not everyone wants a fast program, v. a program written in shorter time, v. a program that is easy to maintain, v. pointy-haired bosses wanting things used that contain buzzwords . Writing a program that runs fast takes more manhours to do successfully than a program that runs slow but was written fast. A program that is easy to maintain takes longer than the slow running program, but not as long as the fast running program (assuming, "fast running," means that interpreted languages are out of the question). A fast running program to not-so-high level things can be written in reasonable time, though, and can be tied in to high-level stuff, if needed (PHP, Python, Lua, etc. acting to control well-tuned bits of programs). And so on. A quickly witten low-level program to do high-level things very fast is going to end up being a long-term failure, 90% of the time. Often times, in balancing all of that, you are way more expensive over the software's life cycle than new servers, workstations, or even raising minimum hardware requirements for the customer.

I'm talking about cases like hundreds of HDD accesses (the OS+FS buffers, you know) or network transactions per second, when one or two would suffice, and also significantly reduce CPU/RAM time-wasting. I'm amazed that some of the things I've seen ever worked at all.

If you are a decent assembly programmer, then you have a solid background to predict and deal with those situations, even if you're not using assembly. Programmers who have never been exposed to assembly usually have to wait until slow response times happen in the test phase.

If you're a decent programmer, learn your tools, and understand your own limitations, you can do that without knowing assembly. I still don't get how assembly has anything to do with that.

If you're putting an implicit POSIX in front of threads, I have yet to grok them, and have no intentions of trying. IMO, Java got threads right (and you won't find me saying much else friendly about Java).

Why? Manually doing threads is awesome! It's particularly exciting in Windows, because its threading system is broken and you have to deal with that fact.

I'd rather be working on my data than fighting the platform (that's one thing I have against both Windows and Java).

Well, that depends. If you can make generic flexible worker processes/threads, and don't rely on very fast responses from pipes, sockets, etc., the OS pretty much will do it for you (don't expect miracles from Windows, though, even then). The real trick is figuring out what you are doing that can take advantage it enough to be worth implementing it.

What a pity! Windows is omnipresent here. To make it worse, SQL Server is omnipresent here as well. Linux sysadmins and Oracle DBAs are particularly expensive.

SQL Server is actually nice, just lacking a bit in DRI. I'd rather use it than MySQL. I don't even want to think about Oracle, though. I went through the, "I should probably learn about Oracle," phase, and basically found it to represent everything I hate in software. I'm itching to professionally work with Postgres, though, especially in a many-server environment.

Assembly is the best way to get rid of mental laziness.

It's a good way to never get anything high level done, too. For a crappy metaphor, it's lazy to cook with a microwave oven. It's not lazy to cook without worrying about how to craft the knife you are using.

Yes, it's a crappy metaphor.

At least I'm honest .

[EduardoLeon]

@ruby
A bit less human readable? Thats the entire point! A language that is natural to program in. (...) Have you ever stopped to think that the great platforms are great because of the language support?

*shrug* Maybe a follow-on will fix those things. The second mouse gets the cheese.

They could start getting rid of features that make the Ruby grammar more difficult to understand, such as "expression if condition", "unless", and other "clever" "syntactic sugar." Or they could throw the whole language out of the window and reuse the concepts invented in the most popular frameworks for it.

@deadlines
Most customers can handle if there page requests are 2ms slower, and would be willing to pay you the same amount(for half of your time. You could always implement an assembly CGI and it'll be damn fast, but really? What is the point?)

My point is that TANSTAAFL. Not everyone wants a fast program, v. a program written in shorter time, v. a program that is easy to maintain, v. pointy-haired bosses wanting things used that contain buzzwords . (...)

The rules are simple: I do it or I'm fired! Of course, I seldom have to use assembly, but I have to take care of user experience (and that includes speed) from the beginning. Especially now that my job is to provide a solution to an NP-hard problem. I also have to do explicit parallelism.

@threading
I like how Posix threads work. They seem like home to me... And I would much rather get a seg fault than the fun error of "This object can only be modified by the thread that created it" Come on C#, you can give the programmer a tiny bit more control can't you?

I'd rather be working on my data than fighting the platform (that's one thing I have against both Windows and Java).

I thought everyone could figure out I was joking when I said I liked Windows threads because they were exciting. .NET and Java don't make reality nicer with their "security," they just make new barriers I must get around.

@IO
I don't think assembly will ever help with predicting which SQL queries run the fastest. Disk IO, maybe.. but still I don't think assembly really helps with understanding the latency of IO

If you're a decent programmer, learn your tools, and understand your own limitations, you can do that without knowing assembly. I still don't get how assembly has anything to do with that.

If you program taking your specific hardware into consideration, your programs can perform better than if you don't.

SQL Server is actually nice, just lacking a bit in DRI. I'd rather use it than MySQL. I don't even want to think about Oracle, though. I went through the, "I should probably learn about Oracle," phase, and basically found it to represent everything I hate in software. I'm itching to professionally work with Postgres, though, especially in a many-server environment.

Oracle is the best RDBMS I have used, period. It's powerful, flexible, scalable, etc. I feel sorry for the poor DBA, though; he looks like a nerd who knows nothing about anything else in real life.

@metaphor
I shouldn't have to understand how the silicon in an OR gate chip works and selectively conducts electricity in order to use an OR operation in a circuit, Nor should I concern myself with the exact mixture of doped silicon and whatever else goes into an OR gate.

In real life, if you are a programmer, most of the time you can't recombine logic gates to make a new processor. But you can reorganize how microinstructions are executed.

[cerbie]

@ruby
A bit less human readable? Thats the entire point! A language that is natural to program in. (...) Have you ever stopped to think that the great platforms are great because of the language support?

*shrug* Maybe a follow-on will fix those things. The second mouse gets the cheese.

They could start getting rid of features that make the Ruby grammar more difficult to understand, such as "expression if condition", "unless", and other "clever" "syntactic sugar." Or they could throw the whole language out of the window and reuse the concepts invented in the most popular frameworks for it.

Syntactic sugar can be good. It's what it gets turned into upon compilation that can make for problems.

I'd rather be working on my data than fighting the platform (that's one thing I have against both Windows and Java).

I thought everyone could figure out I was joking when I said I liked Windows threads because they were exciting.

If I didn't think that, I'd have called you an idiot, liar, or troll. Windows' handling of threading can piss me off with freaking Python, when the same code does what I think it should, after rebooting into Linux.

.NET and Java don't make reality nicer with their "security," they just make new barriers I must get around.

The nice thing is that you can basically do this:

Code: Select all

new ThreadManager TM
for NumOfVisibleCores:
    new MyWork DoStuff (MyWork extends thread, among other things)
    TM.addThread (DoStuff);
...
if WorkNeedsDoing:
    t = TM.getWaitingThread ()
    if t:
        t.run (DoStuff.Copy (whatever)) // this should add a merge request to a queue for some other thread, when done, if sharing data
    else
        TM.ImWaiting = true

...in 50-100 lines. While I'd rather code in C# than Java, they both have the idea of making sure you get stuck in verbose code monkey mode, which can be quite the PITA. It's not security so much as that that is an area where even Java can make for code that's not too big, since what I'm really worried about is handling my data, not dealing with intricate thread semantics. 100 lines in Java is like 5 lines in any language I might really like .

@IO
I don't think assembly will ever help with predicting which SQL queries run the fastest. Disk IO, maybe.. but still I don't think assembly really helps with understanding the latency of IO

If you're a decent programmer, learn your tools, and understand your own limitations, you can do that without knowing assembly. I still don't get how assembly has anything to do with that.

If you program taking your specific hardware into consideration, your programs can perform better than if you don't.

True, but being able to not care about your target is often a goal in itself, and a big reason for the success of Python and PHP, in particular (Java tries, but being one of the first, how it sometimes doesn't do it well will let future attempts succeed better). One of the main ideas is that you can worry about the interpreter and peripherals (well, the idea is not to, but reality sets in, and then...), and everything else gets taken care of. I've personally fixed very bad code from people who thought they knew what was going on underneath, and tried to use that false knowledge, rather than see how well recommended methods work. Forward-looking, I'd like to see a yacc-or-similar->generic cross-platform runtime spec->VM layer chain for language implementation building, to replace current interpreters.

SQL Server is actually nice, just lacking a bit in DRI. I'd rather use it than MySQL. I don't even want to think about Oracle, though. I went through the, "I should probably learn about Oracle," phase, and basically found it to represent everything I hate in software. I'm itching to professionally work with Postgres, though, especially in a many-server environment.

Oracle is the best RDBMS I have used, period. It's powerful, flexible, scalable, etc. I feel sorry for the poor DBA, though; he looks like a nerd who knows nothing about anything else in real life.

Was it an RDBMS (Oracle did make one for a bit, IIRC) or an SQL DBMS or a Oracle VM with SQL-compliant tables? SQL Server and MySQL, FI, have no provisions for relational databases, and require you to use sprocs, triggers, application-layer logic, etc., to do the jobs that basic constraints should do, becoming long-term nightmares for data integrity. Oracle makes it easy to get into its guts (not being able to do that should be a feature). That helps make it so scalable, sure, but also gives such DBAs full time jobs, and not in a good way. Postgres has ways to get around that for scaling out, and allows a well-normalized (>=3NF w/ mostly DRI) DB to be partitioned out fairly logically, which is one reason I'd like to be able to work with it in such environments.

[EduardoLeon]

Syntactic sugar can be good. It's what it gets turned into upon compilation that can make for problems.

Sometimes, the problem is that "clever" "syntactic sugar" has actually complicated semantics. This results in the parser having a lot of work to do.

If I didn't think that, I'd have called you an idiot, liar, or troll. Windows' handling of threading can piss me off with freaking Python, when the same code does what I think it should, after rebooting into Linux.

I am somewhat of a troll, indeed. I like to argue positions most people dislike or don't agree with. In this particular case, it's even better because the position I'm arguing is actually my position on the subject, so I just have to speak my mind instead of coming up with arguments.

(...) 100 lines in Java is like 5 lines in any language I might really like .

Indeed. In C++ (my favorite high-level language), which you might not like, if you allow macro and/or template craziness, MFC/ATL style, you can save a lot of lines of code as well, and also have the benefit of tight execution times.

True, but being able to not care about your target is often a goal in itself, and a big reason for the success of Python and PHP, in particular (...). One of the main ideas is that you can worry about the interpreter and peripherals (...), and everything else gets taken care of.

Python (the only quick-n-dirty language that I can stand) is not that successful and PHP is particularly horrible. For a troll-like remark: PHP makes Perl look pretty.

Was it an RDBMS (Oracle did make one for a bit, IIRC) or an SQL DBMS or a Oracle VM with SQL-compliant tables? SQL Server and MySQL, FI, have no provisions for relational databases, and require you to use sprocs, triggers, application-layer logic, etc., to do the jobs that basic constraints should do, becoming long-term nightmares for data integrity. Oracle makes it easy to get into its guts (not being able to do that should be a feature). That helps make it so scalable, sure, but also gives such DBAs full time jobs, and not in a good way. Postgres has ways to get around that for scaling out, and allows a well-normalized (>=3NF w/ mostly DRI) DB to be partitioned out fairly logically, which is one reason I'd like to be able to work with it in such environments.

Okay, SQL DBMS, as you wish. Having basic constraints would be desirable, but, since computers are not intelligent, they can't compile them into the most efficient stored procedures, triggers, whatever you need to enforce them. So again you are falling into the functional and logic programming traps:

You, who can think, define what needs to get done and the computer, which can't think, finds out how?!?!?! Have you ever considered being a manager?!?!?!

It might be a nightmare to enforce data integrity using imperative (stored procedures) and event-based (triggers) programming, I know, but that's the way how it is.

[Earlz]

@ the "code monkey mode" remark..
Very true..I officially hate statically typed(unambiguity: languages where a variable is always only one type without casting) because of how C# is.. Do you know how hideous something like this is

Code: Select all

((MyEditBoxControl)((ControlListClass)controls)["MyControl"]).Text


It's horrible.. not even that, it's more horrible because it doesn't keep things together. Instead of MyEditBoxControl casting happeneing where the control is actually referenced, it happens much earlier in the line of code leading to extremely hard to read code.. and you can only create so many temporary variables...

Another thing.. I've actually had to use a line like this

Code: Select all

int rid=(int)(decimal)SqlCommand.ExecuteScalar();


The scarier part is that this only happens with some weird variable that is actually an integer in SQL.. soemthign like @@LAST_ROW_UPDATED or something

Syntactic suger is bad for statically typed languages, I agree.. for dynamic though it really makes things more natural....