All I can say is... holy shit. I feel like I have all the power of the Gods at my fingertips... with SQL's insane storage and retrieval capabilities, and Perl's mad data-crunching skillz, I think I'm just about ready to take over the world.

edit : 800th post! w00t!

This message has been edited by damien_s_lucifer on September 23, 2001 at 02:45 AM

Windows has a pretty kickass user interface, but the OS part sucks balls... man, I wish I could run explorer.exe as my X Window manager

------------------
When 1337 hax0rs start impaling each other with swords and typing code with a hook on one hand, then they can modify the term "pirate."

Domain Controllers, whether WinNT or Samba, are machines that admins need to toy with a lot no matter how stable they are. You still need to be able to add and modify user accounts, reset passwords, check the logs, etc. You can do this in Linux, but it's a LOT easier in Windows - which means I can delegate a lot of routine admin-type stuff to the two guys in my department who are pretty good with PCs but don't know Unix and don't have the time to learn it.

At the same time, Web servers, backup systems, and dedicated file servers should be black boxes that do their thing without requiring any user intervention. This is what Linux is really good at. So those systems run Linux. Thank God for Samba.

The point is, I don't care WHO designs what. I use what I think is the best software for the task, and therefore I need software from one vendor to be interoperable with software from a different vendor.

That's why I love Perl - well-written Perl code will execute without requiring any modifications whether you're running Windows, Unix, or Mac OS. That's what I'm hoping open-source .NET will do, too.

MySQL is powerful and it rocks, and MSSQL has a fairly nice UI (for some tasks). I've found that MySQL running on Apache with PhpMyAdmin installed is easier for the most basic database maintenance stuff. I've never needed to make a database that would actually NEED some of the crap that MSSQL has and I don't feel like paying the overhead to run it if I don't need it.

------------------

quote:

---

Originally posted by Dark-Angel99:
How come {name removed} doesn't like you? I find you really funny :D

---

Never argue with and idiot...he may be doing the same thing

quote:

---

Originally posted by Beldurin:
You can...embed it [PHP] within the HTML.

---

You can do the same thing with Perl. You just need to install mod_perl and Apache::ASP for Apache, or use the ActiveState Perl distro for Windows. With ASP you get the same sort of access to the Web server that PHP gives you. PHP is a decent language, but it's not as powerful as Perl

Just wondering. The hardest part of getting Apache::ASP working is building mod_perl. With IIS, you just install ActiveState Perl and the installer will put in the appropriate hooks for you.

On the flip side, a lot of ISPs support PHP, but few if any have Apache::ASP running on their servers. If you want to use it you have to run your own server

getting mod_perl working is a different story though. The problem is that mod_perl has to be built in to Apache, you can't just load it as an .o file. Which means a lot of fooling around with the config scripts to get httpd working the way you want... ::sigh::

It is nice having ASP scripts that run on Unix AND Windows without any modifications, though

In terms of ASP.NET, it is sexy. The background code is not script... it's full blown compiled code. I write mine in C#, but more languages are on the way. Also, they've made it REALLY easy to build web services... basically SOAP calls into objects using XML and HTTP (All open standards ). It takes one attribute tag ( [WebMethod] ) on a function for the compiler to expose it to the world. When I get some of my home network stuff running, I'll expose some web services ya'll can play with.

Anyway, I've fallen in love with it, despite all the bugs that I'm finding in the beta. It's probably the quickest way to do web development possible. Not only that, but things like replacing code/ dlls can be done without having to restart IIS. They included all sorts of little toys.

I just got in a debate with a programmer on the merits of multithreading vs. multiprocessing (fork()). He insisted that multiprocessing is bad programming practice and that any REAL programmer would use threads... it amazes me how zealous people can be when it comes to computers. Personally, my strongest ideology is "I like software that doesn't suck." That's why I like Apache, but don't like the Gimp - I like Linux on a server, but not on a desktop - etc. For some reason this is a very confusing way of thinking to some people

Now that last statement, was a confusing way of thinking

That's how IS (or IT, whatever you like to call them) people SHOULD think damien.

Speaking of Perl... Perl 6 will have a real VM, like Java, with full bytecode support. The bytecode interpreter (called Parrot, after the April Fool's joke of the same name) will be capable of translating the bytecode into native machine language... and it's 100\% open source... time to die, Java, you sux0red from day 1!

This message has been edited by damien_s_lucifer on September 25, 2001 at 12:31 AM

Besides, I love my thread pools. Don't know what I would do without them.

This message has been edited by askheaves on September 26, 2001 at 01:11 AM

quote:

---

Originally posted by askheaves:
I'm coming from a Windows point of view where 1. they make threading REALLY easy, 2. there's a lot of overhead associated with processes 3. interthread communication/ synchronization is a LOT easier than between processes.

---

Okay, here we go... multiprocessing in a nutshell.

I've found that Windows programmers often don't quite get what true multiprocessing is, Unix style. This is because Windows can't do a true fork(), which :

- creates a new process that is an exact duplicate of the parent's machine state, but is otherwise a full process in its own right (it has its own memory space, etc.)

- duplicates ALL the parent's open file and socket handles, so that handle n is the same # for both parent and child, but the child can close or redirect n without affecting the parent.

- resumes execution in both the child and parent processes at the instruction immediately following the fork(). fork() returns 0 to the child and the child's PID to the parent.

A quick example might be :

while (accept(MYSOCK,SOCKET)) # wait for and accept a TCP connection
{
$pid = fork();
if (!$pid)
{
# we're the child, handle the request
process_connection(MYSOCK);
close(MYSOCK);
exit(0);
}
else
{
# we're the parent. Close our new socket since we're not using it,
# save our kid's PID, and go back to waiting for a connection.
push @kids,$pid;
}
}

From there you can write process_connection to act as if it owns the place. It can crash anyway it wants; the OS will just kill that particular child process and the parent will keep running. There's no reason to synchronize or use a mutex or anything else - it will happily handle connections until the hardware dies. Try THAT with IIS

A full process dup sounds inefficient, but Unix uses copy-on-write to duplicate pages so only memory that actually changes winds up being duplicated. From experience, starting an average Perl script takes about 2MB of RAM - but forking only grabs about 100K of memory.

In the real world, you generally use a scoreboard file to get a little more control and efficiency. The example above could take the machine down if you get hit with a few thousand connections all at once, so you need to track how many kids are running and not spawn any more if you hit a maximum.

This is still a *lot* easier than threading - you have two procedures, one called im_busy() and one called im_idle(). im_busy() appends your PID onto the scoreboard file, and im_free() removes it. The parent sits in a loop that counts how many lines are in the file, and spawns more children as needed. The children kill themselves if they don't accept a connection before the timer runs out - calling alarm(30+rand(30)) will take care of that and make sure all the kids don't die simultaneously.

So you have maybe 50 lines of code for the scoreboard stuff, two synchronizing calls per TCP connection - one as soon as you accept(), and one immediately after the close() - and beyond that, you can write your code without another thought to handling multiple connections.

Windows can't do a true fork(), so it's a totally different story. There's no way I would even *attempt* multiprocessing on it; you're basically forced to use threads. I pity you poor fools who don't even know there IS a world beyond your little apartment model...

quote:

---

Originally posted by damien_s_lucifer:
How hard is it to get PHP installed? Is there a version for IIS?

---

Yes there is, and it isn't really that difficult to install. You just have to copy php.ini into your winnt\system32 directory and add the extension filter to IIS (associate .php extensions with X:\INSTALL_DIRECORY\php.exe \%s \%s). The \%s \%s are command arguements for the script interpreter.

It has great MySQL functions built in, and for those of you who use MSSQL, it supports that too if you uncomment the extension in the php.ini file (I prefer Apache and MySQL, but work had IIS4 and MSSQL7 so I had to cope).

------------------

quote:

---

Originally posted by Dark-Angel99:
How come {name removed} doesn't like you? I find you really funny :D

---

Never argue with and idiot...he may be doing the same thing

quote:

---

Originally posted by Beldurin:
(I prefer Apache and MySQL, but work had IIS4 and MSSQL7 so I had to cope).

---

Strange. I'm in the exact same situation

I won't put the code down for a threadpool right now, but I'm much more of the style that I want my children in my process space. That way, if my process dies, everything comes down with it at once and is collected. Two words: "Zombie Processes". And, I think you understand my reasoning for having no choice in this matter under windows from my 3 points. But I don't mind.

The other reason I prefer multi-threading is that everything is in my process space, and I can share resources, as well as synchronize my threads. It's a tricky business, but it's worth it. If I have one handle to a disk or a particular socket, then the first thread that gets to it keeps it until it's done blocking, instead of having resource sharing problems. Plus, my pointers are all valid, so variables can be shared.

Must stop trying to talk technical while drinking... should just get back to coding

It's all about different styles and the platforms we're working on. I love my windows and especially the stuff upcoming. I can't wait until VS.NET finally goes RTM, because these IDE bugs are driving me and my coworkers batty. If you get a chance, you should really delve into this stuff. If you're an object-oriented type, the whole studio is based around an OO runtime. Even VB programmers are forced into an OO style of programming! About bloody time! And I've completely abandoned C++ for C#. It truly is a God among languages. I am finally thankful that I took Java during school. That's all. Threading rules.

Yes, we do come from different programming worlds. Always fun to argue this stuff though. One of the reasons for my thorough explanation of fork() is for all the people who read this forum to learn stuff - and bitch slap you threaders around a bit <g>

Actually, I'm not anti-threading at all. Soon I will be getting a lot more familiar with the pthreads library, because there are plenty of cases where threads are a better solution than a full-blown process.

My biggest beef with Windows - if you haven't already guessed - isn't threading, but the fact that it can't fork. When you can do both, you can pick and choose to get the best of both worlds. MySQL does this, at least under Unix - each DB connection forks a new copy of mysqld, which makes it nice and stable. Then it uses threads to process individual SQL queries, which makes it insanely fast.

Zombies are actually pretty rare. More common is that the parent dumps core, and its children get adopted by init ("orphans"). Both zombies and orphans can be avoided if you make sure your parent code stays clean - a parent process's job should be to keep tabs on the pool of available children, fork() and kill() as necessary, and let the children handle everything else. That way the parent code stays small and simple and isn't prone to crash.

As for OOP - I like objects. Objects are cool. Objects are useful. But I don't like being forced to use them - regardless of the OOP zealots say, a procedural language with OOP functionality is more flexible and more efficient than a pure OOP design. That way you can use what makes sense instead of bending yourself to fit some PhD's ideology.

But I have nothing against forcing OOP on VB programmers. BASIC sucks so hard that there's not much you can do to make it worse

The first year I got to school, we started on C++. Within the year, we were programming in objects. It actually makes a lot more sense to me than anything else. When I read my design patterns book now, it all makes even more sense. The reason OOP exists is to facillitate reuse of design ideas. How else to you get Singletons, and Flyweights, and Compositors, and whatever else. In a procedural setting, you pretty much flow down the code with your brand new idea and way of doing things. I prefer to stand on the shoulders of giants.

For threading/processing, I believe still in threading. I like keeping everything under one umbrella, rather than populate my task manager with hundreds of processes doing menial tasks like monitoring sockets. And, again, a lot of that is because I'm discouraged by the OS. If I were to need that functionality, however, it would be just as easy to build a COM object (Out-of-process) and build it in a single threading model so that I can make multiple instances when I need them. In addition, as the parent of those COM objects, I could let loose the references to them and let them disappear, yet still maintaining control.

Then again, since finding .NET, I've sworn off C++/ATL/COM. I honestly don't know how to do multiprocessing under this framework anymore, but I think I may not need it.

As for objects, I prefer to have a completely object oriented language around, since that's how I program. I don't want to have OOP tacked onto a procedural language just to give me that functionality. Plus, now I have a native String class!!! I've been waiting for that forever! I'm sick of stripping CString out of MFC just to have that. (My last job we had to do that because STL required structured exception handling, which WinCE didn't support all that well).

I suppose I'd be a lot more into pure OOP languages if I hadn't discovered Perl a couple years ago... who needs to deal with a bunch of classes when you have insanely good language-native string and list processing? Of course, objects exist and are used extensively in Perl, but a *lot* of algorithms that used to make me say "hmm, I guess I'll have to make this an object" turn out to be trivial in Perl.

I remember making a whole class structure in C++ so I could do things like implement stacks and iterate over generic lists - something like

code:

---

#include <biguglyclassmodule.h>
void main()
{
 listObject mylist();
 mylist->Add("Hello");
 mylist->Add("World");
 foo = new Iterator(mylist);
 while (bar = Iterator.Next())
 {
  char* s;
  s = bar.Value();
  printf("\%s",bar)
 }
}

---

The equivalent program in Perl is coded as

code:

---

@mylist = ("Hello" , "world");
foreach $thing (@mylist)
 { print $thing }

---

It just doesn't get more elegant than that. And oh yes, you can stick objects inside of lists... and lists inside of lists inside of objects inside a list... ad nauseum.

The downside is that once you get used to Perl, you don't ever want to go back. Two or three years ago I probably would've thought Java or C# was the coolest thing on the planet, but now I see something like

// tons of boilerplate to make the compiler happy
class foo
{
// more boilerplate to make the compiler happy
...a few lines of code...
}
// still yet more boilerplate

and I want to throw the designers out the window. Every time I start to get a little frustrated with Perl's OOP design (@ISA? @EXPORTS? huh?), I just flip open my Data Abstraction and Problem Solving with C++ textbook and remember it could be a *lot* worse.

So explain a bit about this C# thing - I haven't looked at it much, and I'm curious...

This message has been edited by damien_s_lucifer on September 27, 2001 at 11:18 PM

quote:

---

Originally posted by askheaves:
Perl is actually more like the Borg. It just assimilates new stuff from whatever languages are within reach.

---

Which is precisely why it's cool!

It sounds like C# has a lot of Perlish functionality, actually. In Perl, if you do this :

$foo = 3;
$bar = "4";

then $foo is the number 3, and $bar is the string "4". If you then say

$foostr = "There are " . $foo . " foos in here";
$foosandbars = $foo + $bar;

$foo is automatically cast to a string in the first assignment, and $bar is automatically converted to a number in the second.

This is cool :

$users{"syf0n"} = "buttwipe";
$users{"LiNeY"} = "aw3som3 chix0r";

Yep, built-in associative hashes. This is even more fun :

$mysub = sub { print "Just a lil' sub"; };
$callme = &$mysub; # NOT a pointer - this is a reference
$$callme; # Dereference $mysub and evaluate contents

Anonymous subroutines that can be slung around with impunity - mix that with hashes and packages and you get Perl's OOP functionality.

I'll definately have to check out C# now, though. .NET looks really fucking cool, and the next thing for Perl to assimilate... resistence is futile!!!

Time for bed, but before I do I'd like to post the following 100\% genuine log from my latest terminal session. I call it "Damien S. Lucifer's Glorious Return from su Hell :

cmpsys# exit
/d/ics-0: exit
cmpsys# exit
/d/ics-0: exit
cmpsys# exit
/export/home/jesuite: exit
Connection terminated.

That's what happens when you accidentally trash your company's database at 11:30 at night because you thought you were more clever than the OLD sysadmin

Honestly, I was never taught hashes. In fact, I still haven't found a use for them yet. Mostly because I don't do a lot of algorithms for searching and the likes. That kind of stuff is usually encapsulated for me.

Anyway, just a quick aside. I have to get back to work now. Found a use for the Strategy pattern today

Perl is like fortran. Fortran will never die because somebody will invent a new language and call it fortran. Perl is actually more like the Borg. It just assimilates new stuff from whatever languages are within reach.

C# is a whole lot like Java. Actually, a lot like it. The big difference, in the context I'm working in, is that EVERYTHING is an object. If it isn't an object, it's a pseudo-object. Like, int's are native types until you try to use the ToString() function... then they magically become objects. It's rather complicated, but cool. The syntax is very similiar to Java, though. In reality, I loved Java, just felt powerless with it. C# solved a lot of that.

The important thing about .NET is that they basically invented an OO language, built a runtime and framework classes around it, then built a compiler around a syntax. They built a compiler for C#, as well as VB and 'Managed C++'... as well as leaving the door open for other languages. So, everybody programs for these common objects (OS, filesystem, strings, data structures, whatever they included), and the language becomes interchangeable. C# looses a lot of it's benefits over Java when leaving the Windows platform until a CLR is bulit for other platforms. in fact, you could just as easily accomplish the same thing with VB.NET now.

In case you can't tell, I'm totally sold on this whole .NET framework, and it's not my MS-Whorism that's talking. Things like web services, class libraries, etc become a thing of 1-2 lines of code to implement. For example:

[WebMethod]
public string HelloWorld(string strHelp)
{
return "Hello World: " + strHelp;
}

This creates a web method... basically, opens up a service over the internet and makes it possible to call this using a SOAP call, bundled in XML, over an HTTP request to call it. What you get back is "Hello World: " plus that string in an XML structure. It can be more complex than that with little effort. If you're really interested, you'll look into ADO.NET. A new class exists called the DataSet. It is basically a collection of tables, brought back from database calls, that is independant of the underlying database structure. It is automatically serialized to XML and passed over the return call (like, but DataSet instead of string in that call) and can be reassembled on the other end under any platform. It's disconnected by nature, and DB provider indebendant too.

There's just so much magic involved in this new technology that the project I'm working on now relies on it. We're opening up an interface into our services. We're building a kickass Windows UI, but anybody can program toward it under any platform. It's that powerful. MS has taken the right approach by dropping the idea of proprietary COM and instead using open standards. Good Move

I'd recommend finding Beta 2 (I've gotten about 6 copies by now) and playing with it. Play with the UI, ADO.NET, Web Services, class libraries, etc. It's so easy to realize all of those things that would take hours of boilerplate code to accomplish.

quote:

---

Originally posted by askheaves:
[strong typing] keeps you from accidentally confusing the concat + operator or the addition + operator.

---

So does make the + operator do one thing : add. Perl uses . for concatenation.

Which brings up another interesting facet of Perl : it's context-sensitive. In other words, how things get evaluated depends on the context you're evaluating them in.

For example, the expression

$foo + $bar;

is numeric, because addition makes no sense outside of the world of numbers. So $foo and $bar are both automagically evaluated as numbers. If they are strings that won't evaluate to numbers ("1.34" will, but "fuck VB" won't), then they evaluate to 0.

If instead you write

$foo . $bar;

$foo and $bar will both be evaluated in string context. If they're numbers, they'll be converted to strings before concatenation takes place.

More interesting is the difference between

$line = somefunc();

and

@lines = somefunc();

In both cases you're calling the same function, but the first case will return a scalar (a number or a string) and the second case will return a list. The function itself knows what context it was called in, and can adjust accordingly. This is a *very* useful feature. The most obvious is when using the <> operator, which reads in a line from standard input or whatever file you specify:

$input = <FILE>; # Read a single line from FILE
@input = <FILE>; # Read in the rest of FILE, break it apart by line, and stuff the result in a list

quote:

---

Honestly, I was never taught hashes. In fact, I still haven't found a use for them yet. Mostly because I don't do a lot of algorithms for searching and the likes. That kind of stuff is usually encapsulated for me.

---

The reason you don't use hashes a lot is because the languages you use don't support them natively. The concept of a hash is really simple. Think of a database with only two fields : key and data. You store data in the hash by writing

$myhash{'my key'} = $mydata;

which you can later retrieve by writing

$somevar = $myhash{'my key'};

Come to think of it, hashes are a lot like environment variables, except instead of one environment you get as many as you want. (And indeed, access to environment variables in Perl is done through the \%ENV hash.)

Most languages make hashing a complete pain in the ass, so programmers often use other tricks to simulate them - like stuffing things in an array and later reading through the array until you find what you want, or using a B-tree, or other workarounds.

A couple interesting tidbits about hashes :

- A hash is one method of implementing an "associative array."

- Hashing is the only known way of making an associative array work in constant time - i.e. lookups on a hash with a zillion elements don't take any longer than lookups on a hash with a single element. Other methods grow either in proportion to n (searching through an array) or n log n (B-trees).

- There are a couple drawbacks to hashes. First, they usually take more memory than arrays or btrees, and second, they don't sort data as it's inserted like a btree does. But memory's cheap and you don't often need a sorted list of keys, so in most applications the benefits far outweigh the drawbacks.

** sigh ** back to work. My boss wants all user systems documented by Monday... I was going to do it yesterday, but he made me write a "Letter of Intent" to explain to him why he shouldn't fire me. I basically wrote "a. I'm damn smart, b. I'm really good at what I do, c. I'm really good with people, and d. good fucking luck finding another admin that has all of those abilities."

Of course the "typeless" and extremely dynamic nature of languages like Perl and Python can also be drawbacks - you don't get nearly as much type safety as a statically type-checked language, and it's very hard for the VM to optimize or JIT Perl/Python code. (Python basically maxes out at ~10\% the speed of native C code, since there is just no way you can avoid a hash table lookup for every function call; whereas C# and Java on a good VM will be competitive with native C code, because the VM/JIT can exploit static knowledge about the objects it's working with).

I can't use Python for 100\% of my projects because it's just too slow for some things, and the lack of type safety can get annoying. But I wouldn't want to spend all of my time writing C++ or Java code either, because they are just way too strict for quick one-off scripts.

My opinion nowadays is that you need features from *both* ends of the spectrum in a complete development system: statically-typed, optimized code for low-level stuff, and dynamically-typed, easy-to-write code for high-level stuff. You see this pattern in all kinds of software - e.g. Emacs (most code in LISP, running on top of a C kernel), Quake 3 and Tribes 2 (game code in high-level VM "scripts;" also running on a C engine), Maya (GUI code and macros in a high-level scripting language, running on a C++ kernel), most web servers (site-specifc code in Perl/PHP/.NET, driven by a low-level C engine).

My ideal development system would be like today's Python, plus *optional* type declarations for type-safety and runtime speed. This way you could start banging out rough code using Python's dynamic object model, and then move towards type-safe, highly optimized code as your design solidifies... I'm sure an equivalent system could be developed for .NET; basically you'd just need to invent an interpreted "scripting language" that would manipulate objects using the reflection APIs, instead of being compiled down to VM code. (IMHO this is the one piece missing from Microsoft's plan - without a dynamic counterpart to CLR code, it will be hard to use .NET for the kinds of things people do today in Perl and Python)

Looks like I'm going to have to entirely clean out perl & Apache and build from scratch.

::sigh::