isforth linux download

http://isforth.com/download.php?t=linux

sira prise duro tclral raquel relational databases

http://shark.armchair.mb.ca/~erwin/
http://duro.sourceforge.net/
http://computing.unn.ac.uk/raquelDBsystem/
http://tclral.sourceforge.net/

google noop language run on java jvm

http://www.eweek.com/c/a/Application-Development/Google-Delivers-New-Javalike-Language-Noop-473613/

thawte signing certificate howto mykey.pvk mycert.spc from .pfx file

Work around to moving Microsoft® Authenticode® (Multi-Purpose) Certificate to different machines running different Windows platforms
Printer Friendly


Solution ID: SO2694
Version: 4.0
Published: 12/13/2007
Updated: 10/21/2009
Average Rating1 2 3 4 5 2 rating(s)




1 2 3 4 5
Select the number of stars and add (optional) article comments here. To submit click 'Rate'. Rate Problem
Sign code on different Windows platforms
Move Certificate
Move Code Signing Certificate

Resolution
There are two solutions you can try, the first solution allows you to move the Certificate and private key to the new machine as an exported .PFX file(PKCS#12) which signcode will recognise if you specify the -cn parameter, you will be unable to use the .spc and .pvk file therefore the -v and -spc parameters will be invalid.

The Second solution makes use of Openssl and a Windows binary program(PVKTOOL) in order to extract the private key and Certificate from the .PFX backup file and convert the Certificate into a .spc file and private key into a .pvk file which will work on the new machine running the different Windows Operating System.
- OpenSSL is an opensource Unix/Linux based tool used to implement PKI. It consists of a set of libraries, which you compile locally, and is capable of generating keys, certificates, and creating SSL connections to a web server. We use it as a troubleshooting tool for SSL connections and to convert keys into different formats.

- PVKTOOL is a conversion tool created by Dr Stephen Henson which you can use to convert the private key into a .pvk file once it has been extracted from the .PFX backup file and converted into a text format using Openssl. For more information please go to: http://www.drh-consultancy.demon.co.uk

Solution 1:

Using the pvkimprt.exe utility import the Certificate(.spc) and private key(.pvk) into the registry on the machine the Certificate was requested on and then export the keys from the registry as a .PFX file which will contain the Certificate and it's corresponding private key, you can then import the Certificate into IE on the new machine and sign using the -cn parameter in the signcode command line.

Follow these instructions to import the .spc and .pvk files into the registry:

1. Download the pvkimprt tool from the Microsoft site: http://www.microsoft.com/downloads/details.aspx?FamilyID=F9992C94-B129-46BC-B240-414BDFF679A7&displaylang=EN

2. Double click the executable file named pvkimprt.exe

3. Complete the installation process.

4. Import the files using the following command: pvkimprt -import mycert.spc mykey.pvk

5. View the imported files in Internet Explorer > Tools > Internet Options > Content > Certificates

To export the keys as a .pfx file using pvkimprt.exe:

c:\pvkimprt -pfx mycert.spc mykey.pvk

It will bring up the export wizard, in the first window tick "Yes to export the private key", in the second window untick the option 'Enable strong protection..' and tick the option 'Include all Certificates in the certification path if possible', then click next, in the third window specify a private key password(please do not forget it), in the forth window click 'browse' and save the file to your desktop, click next and finish.

Once done, move the .pfx file to the new machine and import it into the IE browser. In IE click Tools > internet options > content > certificates > personal, click the import button, during the process mark the private key as exportable.

You can now sign and timestamp your code(timestamping is optional): signcode -cn "My Organisation" mycab.cab -t http://timestamp.verisign.com/scripts/timstamp.dll

Your code is now signed and timestamped, please run Checktrust.exe to ensure that the file has been signed correctly: chktrust mycab.cab

If you are signing VBA Macros, you can import the .PFX backup file into the IE browser on the new machine and use the VB editor to add the digital signature.
Solution 2:

Secure copy(SCP) or FTP the exported .PFX to your Linux machine. In order to extract the private key from the .PFX file please run the following command:

openssl pkcs12 -in mybackup.pfx -nocerts -out mykey.key

In order to extract the Certificate from the .PFX file please run the following command:

openssl pkcs12 -in mybackup.pfx -nokeys -out mycert.crt

In order to convert the Certificate(mycert.crt) into a .spc file please run the following command:

openssl crl2pkcs7 -nocrl -certfile mycert.crt -outform DER -out newcertfile.spc

You will now need to download the Windows PVKTOOL utility in order to convert the private key(mykey.key) into a .pvk file. Please download the utility from the following link:

http://www.drh-consultancy.demon.co.uk/pvk.html (scroll down to conversion tools and click on where it says Win32 binary here

1.Unzip the file and copy the pvk.exe utility to a new folder named pvktool on your c:\ drive.

2. Secure copy(SCP) or FTP the mykey.key file from the Linux machine to the pvktool folder on the new Windows machine.

3. Please go into your command prompt and change directory(cd) into your pvktool folder.

c:\cd pvktool

4. In order to convert the private key(mykey.key) into a .pvk file, please run the following command:

pvk -in mykey.key -topvk -out newkeyfile.pvk

Once done you can use the private key file(newkeyfile.pvk) and Certificate file(newcertfile.spc) to sign with signcode. Please read the following solution on how to sign with signcode: SO279

Please note that timestamping code allows it to be usable for an extended period of time, as the browser validates the timestamp. If the code is downloaded after the Certificate is expired (and it has been timestamped) you will not receive an error indicating that the certificate has expired. Please specify Verisigns' timestamp server url when you sign a file, the timestamp server validates the date and the time the file was signed. The Certificate expires but the signature will be valid for as long as the file is in production

rc c

(11:01:54 PM) The topic for #plan9 is: Plan 9 from Bell Labs - http://9fans.net | http://lsub.org/who/nemo/9.intro.pdf
(11:02:12 PM) handsumlican_devil: what do plan 9 ers think of forth as a programming language?
(11:06:39 PM) spaceodyssey [n=algol@unaffiliated/fdd] entered the room.
(11:09:26 PM) 1iks: C is the way to go
(11:09:28 PM) 1iks: or rc
(11:09:38 PM) 1iks: specifically about forth I don't know
(11:09:50 PM) 1iks: but C for coding and rc for scripting
(11:09:54 PM) 1iks: mainly
(11:11:31 PM) handsumlican_devil: ok
(11:11:46 PM) handsumlican_devil: can c programs be used by rc
(11:11:53 PM) 1iks: you can do lots of stuff with rc in plan9
(11:11:59 PM) handsumlican_devil: liek say something rc can't do....use c program you wirte to fill gap?
(11:12:08 PM) handsumlican_devil: I am mainly using archlinux
(11:12:18 PM) handsumlican_devil: work has me use redhat linux and solaris sometimes
(11:12:38 PM) 1iks: well, yes I'd say that rc is the first step, what isn't possible with rc you use C
(11:12:47 PM) 1iks: just to give an idea
(11:13:00 PM) 1iks: this irc client is written in irc (the one I'm using)
(11:13:32 PM) 1iks: or programs like contrib/install
(11:13:37 PM) 1iks: etc etc
(11:14:05 PM) 1iks: really many things are in rc AFAIK
(11:14:09 PM) handsumlican_devil: awesome
(11:14:14 PM) handsumlican_devil: so rc can do a shitload
(11:14:35 PM) 1iks: for specific details ask the the rc-cracks here
(11:14:56 PM) 1iks: but as far as I know rc is much tinyer than e.g. bash
(11:15:20 PM) 1iks: plan = less code, but can do more ;)
(11:15:26 PM) 1iks: s/plan/plan 9
(11:18:46 PM) strongbad: plan9, or Plan 9, never Plan9 and rarely plan9 (except in contexts like domain names or file names where both spaces and capital leters are frowned upon)
(11:18:56 PM) strongbad: 07:07 < handsumlican_devil> can c programs be used by rc
(11:19:00 PM) strongbad: is this a joke?
(11:19:05 PM) strongbad: do you people know what a shell is?
(11:19:45 PM) handsumlican_devil: so as lisp procedures can be used at REPL, and tcl can use c programs, the shell of course ok I get it, can use c programs
(11:20:03 PM) handsumlican_devil: as long as c program what writes to std out and err and has exit codes?
(11:20:24 PM) dagle: The shell can run any program.
(11:20:37 PM) strongbad: can bash run perl programs?
(11:20:57 PM) handsumlican_devil: yep
(11:20:59 PM) strongbad: hell, you know where the *name* rc comes from?
(11:21:07 PM) strongbad: Run Commands!
(11:21:07 PM) handsumlican_devil: released code?
(11:22:04 PM) strongbad: I know the world is full of totally braindead shells, but I'm not aware of any widespread shell in the *nix tradition that restricts the commands it can run to any language
(11:23:02 PM) handsumlican_devil: I am going to install plan9 from userspace and try out rc then
(11:23:38 PM) handsumlican_devil: I remembering you saying that the standalone rc by some guy is not as nice..
(11:35:33 PM) handsumlican_devil: strongbad what about forth?
(11:42:39 PM) strongbad: what about it?
(11:44:37 PM) handsumlican_devil: not present in "less harmful alternatives" on harmful website.....

solaris 10 admin guides online

http://docs.sun.com/app/docs/coll/47.16

fossil source code management by sqlite guy

http://www.fossil-scm.org/index.html/doc/tip/www/index.wiki

raid 0+1 best for database

http://www.bolthole.com/uuala/RAID.html

Petabytes on a budget: How to build cheap cloud storage

http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/

solaris 10 cds cd

https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_SMI-Site/en_US/-/USD/ViewProductDetail-Start?ProductRef=Sol10-U7-SP-x86-CD-G-F@CDS-CDS_SMI

solaris 10 jumpstart

http://www.sun.com/bigadmin/features/articles/jumpstart_x86_x64.jsp

Going back to C (self.programming)

http://www.reddit.com/r/programming/comments/aue06/going_back_to_c/



Going back to C (self.programming)

submitted 5 hours ago by buddhabrot

When I was 12 someone gave me a Metrowerks IDE to learn programming on my mac. I learned a lot with it, and got programming in C. I never really wrote a large program in it, only things like ROM hacks that extracted levels and models from snes/psx games I liked. Later, I got a windows PC and messed around with MFC in C++. That was the end for me, programming UI's was too much work in C++ and I couldn't handle the encyclopedic knowledge needed to program the Microsoft framework.

Later, I learned Java, which was also the language most commonly in my college. Making UI's was a blast with it, I could factorize anything and really loved making as generic code as possible with it, even for small projects. Everything I made was made in Java.

Later in uni, I started learning functional languages, we used Haskell in one class. I got intrigued with Haskell and started solving Euler problems, up to this day I still have not written anything useful in Haskell but I love using it.

In the mean time I did some jobs for writing web sites. I used perl and php. After a while I only used php and used it more frequently.

After working for a while as a programmer I started to love higher-level languages, most of all Ruby. I became convinced that higher-level interpreted languages were the future because the slower execution times were to become meaningless. For any web projects I started using Ruby on Rails and to this day it still is my favourite framework.

Then, I learned Erlang because everyone was talking about it, and it showed me how to unleash parallellization, in whole new ways. I still think Erlang is the most amazing language I have ever seen. But then I found out it was also rather slow for the things I had in mind with it. I just didn't find any use for it and never completely learned the language.

Last week I wanted to make a big poster of a fractal. I wanted to compute it on a friend's octocore, and write a fast parallellized program. At first, I used Ruby, thinking it would perform better than I thought. And I quickly abandoned the idea because it was too slow.

Then I rewrote the same single-threaded algorithm in Haskell and saw that it was much, much quicker. But when I tried to parallallize it, I couldn't fathom how to do it in Haskell and abandoned the idea. I tried to write a parallellized version in Erlang, and while it spreak across the machine nicely, each individual process was way too slow, the parallellized algorithm was hundreds of times slower than the single-threaded haskell.

Because I really wanted that poster, I decided to switch to C because I had this idea that nothing could fail in C. And I started to code in a language I hadn't used for years, even a decade. And suddenly it hit me, everything made sense. Sure, I was writing so much boilerplate but it didn't bother me. I suddenly realized that everything I wrote would be inside the program's code, and that nothing more would. It was a great feeling.
I used simple pthreads to do the parallellization, and I used libgd to output my data to a png file. I started learning about mutex lock hierarchies to make the parallellizations overlap without endangering thread safety, it was all ugly code and the API's felt horrible compared to what I was used to.. but it all worked out. The resulting program was thousands of times faster than anything I had written.

And now, I am seriously wondering where I have been all this time. Sure, I still think C is incredibly clunky. But now I got the dust off of my old course on writing compilers (Modern compiler implementation in C), and I want to write a compiler in C for a small programming language. I want to get down to earth again, and write things that are efficient and just run very quickly. I want to write lots and lots of code and know exactly what every line does.

Has anyone else had this feeling, this evolution? Am I going mad? Do you think C will last, and there are intersting jobs left for pure C developers?
208 commentssharesavehidereport
comments
sorted by: new200

formatting help
save


chmod700 1 point 3 minutes ago[-]

I run gmake and gcc, And I ain't never called malloc without calling free.

You kids get off my lawn with your ruby, java, vm crap. They're all written in C.
permalinkreportreply


frikk 1 point 8 minutes ago[-]

So... about that wall-sized fractal generator. Source? I'd love to make one of those!
permalinkreportreply


MpVpRb 1 point 13 minutes ago[-]

I do embedded systems programming.

I program in C and C++.

I use C++ in a fairly minimal way...

No MFC, ATL or templates.

No complex constructors.

No complex inheritance.

Dynamic object creation only when necessary.

I like simple.
permalinkreportreply


STATUS_SUCCESS 1 point 15 minutes ago[-]

Welcome back to programming.

One of the reasons the languages you mention even exist is the ridiculously fast hardware that has become available over the years.

"Is this possible on this hardware?" is not a question asked by very many programmers these days.
permalinkreportreply


nint22 1 point 30 minutes ago* [-]

I find it funny you said C is clunky. Yes, it's quite a "verbose" language with the old concept of header files that unnecessarily repeat lines of codes, but it's nothing compared to the bloat and overhead of Java, C++, etc. OOP languages are notorious for the boilerplate code; even if you are a good programmer, the language forces you into such bad styles.

Now, this isn't a bash against all aspects of OOP languages! Yes, OOP languages do have their strengths, and no, I'm not saying C is better than other languages - just pointing out that C is far from "clunky". I would have to say it's one of the "slickest" languages designed!

edit: dwchandler says it very well :-)
permalinkreportreply


p0nce 1 point 34 minutes ago[-]

D
permalinkreportreply


TiltedPlacitan 1 point 35 minutes ago[-]

You have been a victim of the "language of the month club". Welcome back. We missed you.

In the meantime I've been working almost exclusively in C and C++ - and have developed quite a library of code in this environment.

Yes, we C folks still exist. Yes, there are jobs. Yes, there are interesting projects - particularly in the embedded space. Get yourself back up to speed and join us.
permalinkreportreply


stesch 0 points 53 minutes ago[-]

People thought I was mad when I asked Are there any good and free libraries to develop web applications in C? on Stack Overflow.

This was over a year ago when I got frustrated with all the current languages I'm using and playing with.
permalinkreportreply


smakusdod 1 point 58 minutes ago[-]

Try c#. Don't hate what you don't know.
permalinkreportreply


mysticalfruit 1 point 59 minutes ago[-]

Congratulations and welcome to the club! Now you're really a programmer which means that you're not tied to a particular language. You use the tool that's best for the job at hand.
permalinkreportreply


adraffy 1 point 1 hour ago[-]

you could do this as an "1-liner" in mathematica, including both parallelization and a fancy gui for parameters.

sure, c will always exist; the c-style langs are great for taking a concrete solution/process and turning it into a stable application.

but when i write software, it's to find answers to questions in a reasonable time frame. low-level implementation is not my concern until i hit a wall. and even then, it's often cheaper and faster to throw more machines or ram at the problem than deal with optimization.
permalinkreportreply


tomazk 1 point 1 hour ago[-]

Modern compiler implementation in C - and I want to write a compiler in C for a small programming language

by Andrew W. Appel i presume?

What are your expectations on this? Because I must warn you that implementing a compiler that is being used in this book (or later versions of it) will not get you very far unless you can spare about 10-15 hours of pure programming a week - and it takes about 12 weeks to finish.

At the end you will end up with a pretty much useless compiler and a language that can solve only basic problems.

The later version of the book got me trough a rather buggy and non optimised compiler - implemented in Java - that can compile programs for a ARM platform. Designing such a compiler got me some basic understanding of how compilers should be built and i started appreciating the work of gcc creators :)
permalinkreportreply


buddhabrot [S] 1 point 1 hour ago[-]

Yes, the Appel book.
I'm going to use an external lexer and parser, I don't see the point in writing my own. I will try everything from AST myself and skip some steps to the target language (I don't think I'll target machine code but would like to build a very small domain language on top of C). Frankly I don't know what I will end up with.. writing my own little language just seems like somehting I have to do.
permalinkparentreportreply


paradgim 2 points 1 hour ago[-]

I have had a similar path to you - starting in the same way (with Turbo C in 1988), but with industrial use of C later on as I left university, but the path is the same, and I have ended up with Erlang. With the latest release, you have NIFs, which are native implemented functions - you can write all the computationally expensive code in C, but still have the ease of use, flexibility and productivity gains you have with Erlang. The NIFs behave exactly as erlang functions, but execute with the full speed of C. In short I can build applications many times faster than anything else, but have the computational capacity of C where needed. It has really been an awakening.
permalinkreportreply


bitwize 1 point 1 hour ago[-]

You are maturing as a developer.

In your youth you probably thought -- much as I did -- that C++ must be better than C; look at all these new features it has! It's inherent even in the name!

As time wears on and angle-brackets from template declarations grate against your soul, you will learn, again as I did, that given two ways to do something -- the C way and the C++ way -- the C way is almost invariably simpler and cleaner.

Welcome back. May your pointers never dangle.
permalinkreportreply


SteveJorgensen 1 point 1 hour ago[-]

I don't think you're going mad at all. Each language has its appropriate and inappropriate places for use, and perhaps this is one perfectly (or at least very well) suited to C.

I am also a Ruby fan with some programs I'd like to write for high performance and concurrency. I've been considering trying out IO Language http://iolanguage.com/ to see if I can have the best of both worlds (or at least much of the good of both).

Has anyone here tried using IO?
permalinkreportreply


collegefreshman 1 point 1 hour ago[-]

Blasphemy. C is the creation of the Devil.

Then again, I am the guy who has been sheltered his whole life with stuff like Java and MATLAB.

Maybe I will appreciate C, some 5-6 years down the road, but currently, I can't fathom using it for my own stuff.

--a new guy to programming
permalinkreportreply


alaskanpimp 1 point 1 hour ago[-]

Great little read! Perhaps you should get a job doing embedded stuff. C is certainly not dead in that regard.
permalinkreportreply


ModernRonin 1 point 1 hour ago[-]

Has anyone else had this feeling, this evolution?

Some of us just never left C. I've programmed extensively in Java, Perl, and my current paycheck comes from ActionScript. I still like C better, and always have.

Am I going mad?

(Cheshire Cat) We're all mad here. (/CC) ;]

Do you think C will last,

Its death will be slow. Higher-level languages will replace it for specific tasks (web developement is the obvious example), but C will often be found lurking under the covers, in places where performance or memory consumption actually matters.

and there are intersting jobs left for pure C developers?

Embedded System is generally very interesting, and will require you to be good at circuits as well as code.
permalinkreportreply


Riesling 1 point 1 hour ago* [-]

Nice that you found your joy in programming low level languages again, but I according to your requirements I have the perfect language for you: Scala

Later in uni, I started learning functional languages, we used Haskell in one class. I got intrigued with Haskell and started solving Euler problems, up to this day I still have not written anything useful in Haskell but I love using it.
Functional Programming supported [checked]

Then, I learned Erlang because everyone was talking about it, and it showed me how to unleash parallellization, in whole new ways. I still think Erlang is the most amazing language I have ever seen.
supporting the Erlang "actors concept" [checked]

I wanted to compute it on a friend's octocore, and write a fast parallellized program.
having an Java equal performance [checked]

Edit: Forgot to mention that the poster is really cool!
permalinkreportreply


negascout 2 points 1 hour ago[-]

You didn't hate programming GUI in C++... you hated programming against MFC. C++ is fantastic with the right library choices.
permalinkreportreply


fmoliveira 1 point 2 hours ago[-]

My greatest disappointment with C was incredible boring stuff that wasn't even supposed to be written in C. In one I ended working more with .INI files than with the code. In the other, I was doing a website using C and some inhouse outdated, slow, clunky, terrible framework. Them I ended doing something interesting for a while, now I'm doing boring shit again.
permalinkreportreply


foobaar 1 point 2 hours ago[-]

C is as close to assembly as you can get. As long as there is new hardware coming out, C is irreplaceable. Porting existing software, writing new device drivers or just fine tuning is all done in C.
permalinkreportreply


matjam 14 points 2 hours ago[-]

Other programming languages make you a better C programmer.
permalinkreportreply


tpk1024 1 point 55 minutes ago[-]

This comment made my day :)
permalinkparentreportreply


foobaar 0 points 2 hours ago[-]

Ha ha nice.
permalinkparentreportreply


Araucaria 1 point 2 hours ago[-]

You can make your C programming totally awesome by using m4 macros instead of cpp.

M4 is everywhere (it's used in autoconf). If you use a Makefile to convert your file.c.m4 into file.c, your debugger will find the actual text being run, instead of some weird preprocessor line.
permalinkreportreply


balau 3 points 2 hours ago[-]

Don't worry: C will last, because of embedded platforms and Linux kernel.
permalinkreportreply


Jey_Lux 3 points 2 hours ago[-]

tl;dr: I thought C was stupid, I tried everything else trying to replace it over the years, and came back full circle. I now love it, because i finally have enough practical knowledge to appreciate it for what it really is.
permalinkreportreply


tybris1 2 points 2 hours ago* [-]

People forget the best engineering solution is always in the middle. More than any other language, C fits in between the human mind and the metal. You can try to make it more extreme, but you're only going further from the ideal. Of course, a language that is tailored to a specific type of problem works better for that, but for the general case C is just fine.
permalinkreportreply


Wendel 1 point 2 hours ago[-]

I find COBOL exciting.
permalinkreportreply


madman1969 3 points 2 hours ago[-]

Exciting like a heart-attack ?
permalinkparentreportreply


royrwood 8 points 2 hours ago[-]
Write it in something like Python first, get it working
Profile it, identify the processing bottlenecks, code those bits in C
Profit....
permalinkreportreply


bluGill 0 points 49 minutes ago[-]

There is a lot of optimization you should do in python before dropping down to C. The easy way isn't always fast. Spend your time researching algorithms for the slow parts before you drop back into C. Dropping into C from python can give you at most a 60x speedup. Sticking to python, but using a better algorithm can give you 100,000x speedup. Once it is working in python you can go to C and get a 1,000,000x speedup over the original. (Not 6,000,000 as you might guess: optimized algorithms tend to use much faster python code paths)
permalinkparentreportreply


brave_sir_robert 12 points 2 hours ago[-]

2b. realize you're losing 80% of time waiting for a socket or the disk anyway...
permalinkparentreportreply


TiltedPlacitan 1 point 23 minutes ago[-]

So export the processing of sockets/disk writes to separate threads or processes.
permalinkparentreportreply


twotime 2 points 43 minutes ago[-]

2b. realize you're losing 80% of time waiting for a socket or the disk anyway

I am not so sure about waiting for disks ;-(.

I'm yet to see a non-trivial python program which would be local IO-dominated...

All the IO-intensive python code which I ever looked at was CPU bound ;-(.
permalinkparentreportreply


QuantumFTL 2 points 2 hours ago[-]

You might find some modern assemblers to be more useful, if you want better control over what's in your code. Indeed, assembler macros are so good that you can write code that's easily much higher level than C, without sacrificing much (perhaps a little time figuring out how to use it).
permalinkreportreply


Lyjontko 0 points 2 hours ago[-]

Dude C/C++ is THE shit.
Also, pointers.
permalinkreportreply


ghostvillain 8 points 2 hours ago[-]

I think you were impressed by C because you had a clear and relatively self-contained objective in mind, and could picture the whole development process in your head. In situations such as this one, most of the features of the higher level programming languages become cruft, and you are happy to give up abstractions for raw speed and control.

My suggestion is: go ahead, write some more code in C.

After a while, as your code grows more and more complicated, the lack of abstractions will kill your enthusiasm. You will remember what's so great about the high level languages you mentioned, and you will find an excuse to switch to a project where speed is not essential, so that you can finally ditch C for good :)
permalinkreportreply


Biber 2 points 2 hours ago[-]

and you will find an excuse to switch to a project where speed is not essential, so that you can finally ditch C for good :)

Bill Gates is that you?
permalinkparentreportreply


buddhabrot [S] 3 points 2 hours ago[-]

I hope you're wrong :)
permalinkparentreportreply


ghostvillain 2 points 2 hours ago[-]

Why?

We're slowly getting to the point where any language can be as fast as C, or at least will allow you to pay (performance-wise) only for the features you actually use.
permalinkparentreportreply


buddhabrot [S] 2 points 1 hour ago[-]

That's the opposite of the truth? I could write this algorithm as literally as possible in Python and it would still be hundreds of times slower.

I'm just wondering if all those language constructs that essentially just remove boilerplate actually amount to anything, in the end. Aren't all the really good things written in C? Aren't Python and Ruby written in C?
permalinkparentreportreply


andyou 3 points 2 hours ago[-]

Have you tried D? Having played around with raytracers, fractal 2d and 3d generators and all kinds of brute force procedural graphics in c, c++ python etc.. D is awesome, just a shame there arent as many libraries yet.

ps. Post the image.
permalinkreportreply


buddhabrot [S] 3 points 2 hours ago[-]

Haven't tried D, not sure if I want to learn it.
Lower res/depth output with coloring is here: http://dl.dropbox.com/u/3545003/buddhabrot.png FUll version is still rendering, will take 24 hours.
permalinkparentreportreply


losewinspin 5 points 2 hours ago[-]

Well, we all know that it is extremely unlikely that you can travel faster than C. :-)

You might want to look into Ocaml and Go though. Save yourself a few pointers.
permalinkreportreply


TomSwirly 4 points 2 hours ago[-]

First, I hope you're talking about C++ and not just pure C. It's 2010, there's literally no reason at all not to use C++ if you're wanting to use C.

Most C programs are also legal C++ programs, all C programs can trivially be changed into C++ programs, the efficiency of the generated code will be exactly the same; but the advantages of using the STL cannot be overestimated, if only std::string and std::vector.

That said, there are thousands of C++ jobs out there. I just "retired" after five years at Google where I spent nearly all my time writing C++ (and boy, are my arms tired!) Google alone employs probably thousands of C++ programmers; I'm sure Microsoft does also; anyone who writes games, device drivers, real time programs of any type, all of them need C++ programmers.

Now, my favorite language these days in Python (though this week I'm writing music programs in Javascript, long story...) because it takes me literally less than a third the time to write the same program, because my program quality is better and because I can manage complexity a lot better that way.

But Python is slow - it uses a lot more of your CPU. Nearly all the time, I simply don't care - my CPU is sitting there doing nothing anyway, it's likely that my program is spending most of its time waiting for the disk or the network anyway, and can I really tell the difference between 1ms and 10ms anyway?

But sometimes I really do care. And when I do care about speed, or memory, or I have some other serious hardware or system limitation, then C/C++ is the only possible choice.

I like Java - and for many applications, it's "almost" as fast as C++ - it's good for server-side manipulation. Hotspot is amazing, and will often generate code that's faster than a C compiler could ever do, because it can optimize for the specific processor that the code is running on, rather than a generic Pentium-class processor. But it's big, and in practice, you can simply get better overall performance, and definitely a much smaller memory footprint, from a C++ program.
permalinkreportreply


drewc 13 points 2 hours ago[-]

It's 2010, there's literally no reason at all not to use C++ if you're wanting to use C.

... And there's no need to read the rest of your comment when you start with such an idiotic statement.
permalinkparentreportreply


wnoise 8 points 2 hours ago* [-]

The problem with using just the simplest features of C++ is that they act as a gateway drug to using the features that should work, but just end up fucking your program.
permalinkparentreportreply


jonask84 3 points 2 hours ago[-]

Ah, it warms my heart to read this. It is so true though, you have to part with a bit of your programer's soul when you move up from C.

Sure the C#s and pythons of the world are convenient and comfortable, but any programmer worth his salt should know and love C for it's close relation to asm and machine code.

Good for you man, wb!

btw, that octocore, is that a hyperthreaded quadcore (boo!) or a genuine 8 core monster?
permalinkreportreply


buddhabrot [S] 4 points 2 hours ago* [-]

It's the real thing :) http://www.apple.com/macpro/
permalinkparentreportreply


whosyerparrot 0 points 36 minutes ago[-]

oh god, the mac pro has got to be one of the most overpriced computers...
permalinkparentreportreply

fired comment score below threshold[+] (0 children)


z0ltanz0ltan 4 points 2 hours ago[-]

This is the first time I am going to thank anyone in reddit for truly re-inspiring me (and I have an inkling it may also be the last). Just reading through your text section made me realize why I got into the IT industry in the first place. Somehow over the last few years I had got jaded and became more of a code monkey than someone who loved the very concept of 'programming', the wondrous magical possibilities inherent in it and truly something that one has to love to master. I will be quitting the industry per se soon, but I will always harbor a love for, and will definitely indulge in it throughout my life - just without the ennui, drudgery and plain moronicity of the trade. Thanks, friend, and good luck with your love of the art. Hope it lasts a lifetime!
permalinkreportreply


awj 10 points 3 hours ago* [-]

C is great. Most of the scripting monkeys you hear proclaiming its demise fail to realize that their entire world is built on C. Sure it can be ugly as sin, manual memory management is a pain in the ass, and (IMO) threading is even harder, but it gets the job done where nothing else seems to.

That said, I'm going to strongly suggest learning how to write bindings in $favorite_scripting_language. There's a lot of glue work out there that these languages excel at. Ruby, Python and (from what I hear) Erlang are relatively simple to write bindings for, which lets you try to grab some of the best of both worlds.

Your Erlang solution, for instance, could have used Erlang to distribute the workload and some C to do the actual work. I wouldn't be too surprised if Erlang could rival and/or beat your pthreads code at distributing the work, and either way it obviously would be easier to adapt to some kind of multi-machine fractal farm.
permalinkreportreply


logicalmind 1 point 26 seconds ago[-]

COBOL is great. Most of the scripting monkeys you hear proclaiming its demise fail to realize that their entire world is built on COBOL. Sure it can be ugly as sin, manual memory management is a pain in the ass, and (IMO) threading is even harder, but it gets the job done where nothing else seems to.
permalinkparentreportreply


tgbyhn 5 points 3 hours ago[-]

Haskell is one of the best languages for creating compilers, IMO. C has a lot of advantages in many domains, but compiler writing isn't one of them.

The trick with Haskell programming is ignoring all the people that are doing incomprehensible things with the type system.
permalinkreportreply


ungulate 2 points 1 hour ago[-]

The trick with Haskell programming is ignoring all the people that are doing incomprehensible things with the type system.

This is true for C++ as well, and increasingly so for Java. Some programmers are just hell-bent on creating their own new languages by torturing type systems.
permalinkparentreportreply


tgbyhn 1 point 18 minutes ago[-]

Agreed. Here's a representative example: http://www.reddit.com/r/cpp/comments/au1sq/the_safe_bool_idiom_learn_how_to_validate_objects/

After reading the article, see my comment in the reddit discussion.
permalinkparentreportreply


mpr312 1 point 1 hour ago[-]

Hugs is implemented in C for performance reasons.
permalinkparentreportreply


buddhabrot [S] 2 points 1 hour ago[-]

Hugs isn't a compiler, and I can't remember it being faster than ghci.
permalinkparentreportreply


self 2 points 1 hour ago[-]

Are you sure it's not for bootstrapping issues? If Hugs was written in Haskell, how would you get it up and running on your platform? A lot of compilers/runtimes (POC, GHC, Gwydion Dylan, etc) run into this problem.

Has anyone tried rewriting Hugs in Haskell, to be compiled with GHC?
permalinkparentreportreply


buddhabrot [S] 2 points 3 hours ago[-]

Heh, that last bit is probably great advice! #haskell is probably the best irc channel out there but it is terribly confusing.
I understand that C might be a bad choice for a compiler, I just dug up all old C books I had and compiler writing in C was one of them.
permalinkparentreportreply


stillalone 1 point 3 hours ago[-]

I know that feeling, but I feel it is more of a curse. I'm always concerned about efficiency. When I code in Python or any other high level language I worry about what libraries to use and what functions to call. But in C, it's always better to code it yourself, because you have specific needs. So I end up wasting so much time trying to save a few kilobytes off my executable and an unnoticeable performance gain.
permalinkreportreply


ahminus 5 points 3 hours ago* [-]

Your post was very interesting for me. For about 2 years now, my mantra has been "C is all you need" (which, is, of course, a bit tongue-in-cheek). It was born of a journey which parallels yours pretty closely. I suspect I'm about 10 years older than you, though.

I started in Object Pascal on one short project as a research programmer in college, and went on to do several projects in C++ with MacApp, after which I spent several years with CodeWarrior (on Mac and Linux), and programming NeXTSTEP (Objective C).

I then spent about 5 years in Java-land (working on a well known IDE from a Big Successful Java Enterprise company) and dabbled in Python and Ruby (and, I'm loathe to admit, even some PHP).

For the last 5 years or so, I've worked pretty much exclusively with C (and some occasional) C++, mainly working on networking and simulation code for MMOG backends.

I really don't think I'll give up C before my career as a programmer ends.

Truly good C programmers know that other languages only buy you something if you're not already a good programmer. There are many many open source libraries and applications written entirely in C which are much more "object oriented" and embody all the precepts that OOLs are supposed to grant you than the majority of applications written in said OOLs.

When I first started programming in dynamic languages and other languages with runtimes, I found certain features to be hugely advantageous (reflection, ease of dealing with heterogenous containers, etc.), but my love for languages with a runtime waned over the years as I more and more felt like I was just poking at a box with a stick sometimes, trying to figure out why code wasn't working as it should, or more often, was performing horribly.

At least with C, I can look at disassembled code in the debugger, and the profilers are much more helpful than with any other language I've used (including in Java-land, where there are good profilers).

Also, all the most used software in the world is still written in C/C++: every popular operating system, all the popular web servers, every popular web browser, almost every office suite, and almost every video game on PCs and consoles (including all those handhelds), and a whole lot of mobile software.
permalinkreportreply


chmod700 1 point 7 minutes ago[-]

Well said.
permalinkparentreportreply


hiker 3 points 1 hour ago[-]

The more you know, the less you need.
permalinkparentreportreply


TiltedPlacitan 1 point 16 minutes ago[-]

Enthusiastic upvote from another minimalist.
permalinkparentreportreply


antareus 2 points 3 hours ago[-]

The reasons you state are why I stick with C++ for hobby projects. I like being able to produce tiny, standalone executables that have zero dependencies. I also like the ability to construct decent abstractions once I've figured out which ones are necessary.
permalinkreportreply


goggles2 8 points 3 hours ago[-]

Yes, going back to C from the popular scripting languages, the first thing you notice is how freaking fast it is. I mean, it's just "knock-your-socks-off" "jaw-hanging-open" "holy-crap-that-was-fast" fast compared to Perl/Python/Ruby.
permalinkreportreply


brave_sir_robert -1 points 2 hours ago[-]

... until you write one I/O call ...
permalinkparentreportreply


twotime 1 point 27 minutes ago[-]

Not in my experience. Not with local IO.

Any IO-bound non-trivial C program suddenly becomes CPU-bound once you rewrite it in python.

I'd be curious to hear if you had different experience.
permalinkparentreportreply


bibster -4 points 1 hour ago[-]

downvoted you because it's brave sir robin, not robert.
permalinkparentreportreply


acow 10 points 3 hours ago[-]

I can sympathize with this experience, and I find it an interesting commentary on C. When I do go back to C, I am initially very impressed by how straightforward it is to write programs that run very quickly, but that impression often wanes as the application grows and I find myself thinking, "If only C had this one little extra feature, then it would be a serious contender for even more programming tasks!"

And yet, when you look at all the would-be successors to the throne, the sum of the "little features" becomes a flood that hides the landscape you loved. For example, I sometimes feel that I should use C++ rather than C more often. When I start in such an effort, I do indeed take advantage of the greater support for abstraction and encapsulation, but the amount of boiler plate syntax becomes a turn-off. Then, when I find a surprising performance pitfall through some use of an iterator or template or other C++ feature, I can't help but think that I've lost C somewhere in there. I think that it's just harder to shoot yourself in the foot with C because it's so much harder to use it to build a gun.

As for C being replaced, it's not clear that it needs replacing, but my usual answer to this is that its usefulness will be diminished the farther hardware moves from C's implicit model of the computer. Such differences (e.g. memory hierarchies not necessarily apparent at the C level) have, as far as I can tell, yet to have a large effect on C's applicability, but who knows how things will go?
permalinkreportreply


TiltedPlacitan 1 point 25 minutes ago[-]

I think that it's just harder to shoot yourself in the foot with C because it's so much harder to use it to build a gun.

This gave me a chuckle. IMO, C is the language that makes it too easy to unintentionally build a bomb that blows up the amateur coder.
permalinkparentreportreply


zem 2 points 1 hour ago[-]

the two 'one extra feature's i want are decent string handling and lexical closures. so far, D, vala and objective c seem to be stepping up to the plate.
permalinkparentreportreply


acow 2 points 1 hour ago[-]

In a way they are, but my point is that D, Vala, and Objective-C do not at all resemble C + my-most-wanted-feature-at-this-moment. C is a line in the sand, and attempts to slightly blur it seem to inevitably end up diverging dramatically.
permalinkparentreportreply


zem 1 point 33 minutes ago[-]

this is also true. and everyone wants a different 'one extra feature'. though i'd bet a decent string handling library with syntactic support would be on everyone's list.
permalinkparentreportreply


antareus 5 points 3 hours ago[-]

Then, when I find a surprising performance pitfall through some use of an iterator or template or other C++ feature, I can't help but think that I've lost C somewhere in there.

Read through your C++'s implementation of iterators and decide whether it is OK. Most of the typical ones are little more than pointers which are checked before being dereferenced. As for template performance characteristics, that is entirely dependent on what type you're using (a value or a reference?) and how you're using it.
permalinkparentreportreply


acow 2 points 3 hours ago[-]

Sorry, I wasn't trying to suggest a fundamental limitation, but rather the danger of hurting performance in order to fit into a well-supported abstraction.

The C approach of allocating a block of memory then poking pointers is very flexible, and it's easier to accidentally fail to, say, pre-allocate a vector when using more full featured collection classes. Of course the standard libraries excel in the general cases, but it's the very specific cases where you know, or think you know, exactly what needs to be done that they can be a hindrance over the straightforward C approach.

Don't get me wrong, I spend most of my time in languages other than C these days, but I still believe that C's transparency with regard to what the machine is doing can certainly be illuminating.
permalinkparentreportreply


antareus 1 point 2 hours ago[-]

The C approach of allocating a block of memory then poking pointers is very flexible, and it's easier to accidentally fail to, say, pre-allocate a vector when using more full featured collection classes.

Absolutely. Failure in the C case is much easier to handle -- generally, if malloc fails. You are SOL if that happens and it may be better to dump core immediately. In C++, new might throw, and the temporaries involved in initial construction of the vector might throw, too. You don't know -- you hope the caller knows. This also imposes the burden of exception-safety on all the callers until the exception is actually handled.

By virtue of being higher-level, STL makes it easy to forget that sometimes a simple, contiguous block of memory offers much better performance due to cache coherency.
permalinkparentreportreply


smcameron 1 point 1 hour ago[-]

By default, on many OSes these days, malloc won't fail, because you'll have virtual address space. Instead, the OS will overcommit, and malloc will happily proceed to hand you a pointer, and then when you try to access that pointer, the OS will scramble to meet its overcommit, fail, and kill your process. Checking malloc's return is a fool's game on such OSes.
permalinkparentreportreply


eallin 6 points 3 hours ago[-]

Most people focus on writing abstractions in high-level languages these days. It's great for a while, because you get things done really quickly... but then you get really tired of having no idea what you're doing. I used to write networking code in C and I learnt a lot about networking/sockets etc. With python + twisted, I can make things "just work", but I haven't a clue about what's going on underneath. Everything is an abstraction... factories, reactors etc. In theory it's great: especially if the libraries are really well-documented.

People like bashing C in order to promote ruby/haskell/python (which are all great languages), but how come there's so few apps written in those languages? In my job I use FreeBSD, Postfix, Apache, BIND etc. and they're all written in C.
permalinkreportreply


self 1 point 52 minutes ago[-]

I used to write networking code in C and I learnt a lot about networking/sockets etc. With python + twisted, I can make things "just work", but I haven't a clue about what's going on underneath.

You could write your networking code on plan 9, and never deal with sockets. You'd still write your code in C, but the platform takes care of the 'magic'.
permalinkparentreportreply


eallin 1 point 41 minutes ago[-]

That seems better than both of the other alternatives. However, it would probably not work on any other platform or production environment? I don't know much about the current state of Plan 9...
permalinkparentreportreply


self 1 point 17 minutes ago* [-]

You can fake it somewhat with plan9port, but it's not ideal. It just ends up being an abstracted layer on top of sockets.

My point was that it's not programming in C that gave you a deeper insight into how sockets/etc work; it's that sockets were the lowest available abstraction on your platform.
permalinkparentreportreply


flogic 2 points 2 hours ago[-]

BSD and Bind of those are OLD. Apache is old enough for C to have been the correct choice for performance reasons. I suspect the same applies to Postfix. Truthfully we're only just getting to the point where the better languages are fast enough and have enough libraries. For instance Ocaml Batteries included only just hit 1.0. Chrome's V8 is still relatively new.
permalinkparentreportreply


eallin 4 points 2 hours ago* [-]

Perhaps you are right, but that's what they said about Haskell, Arc, Ruby etc. "They're new, but with a few years on their back..." I wasted a lot of time waiting for Common Lisp, Python and whatnot to become "the new C". After giving up a few times, I decided to embrace C.
permalinkparentreportreply


dfj225 7 points 3 hours ago[-]

The truth is, C is the lingua franca for high performance computing. It seems like the major requirement for your fractal code (other than generating fractals :-P) is that it runs quickly. Since this is a requirement, I think C is probably the best choice. You could probably use some C++ in there, but I think that most compilers will generate faster code if you use C for the heavy computation portions of the code.

I don't envision C being replaced any time soon for HPC code. Other languages (especially interpreted / JIT langs) will get faster as time goes on, but I'm not sure if they will ever remove all of the overhead from interpretation / compiling on the fly.
permalinkreportreply


syntax 12 points 2 hours ago[-]

The truth is, C is the lingua franca for high performance computing.

Fortran is the linga franc for High Performance Computing.

That is, if your runtime is measured in minutes, your doing high performance computing.
If your runtime is measured in days, your doing High Performance Computing, and talk about MPI and clusters a lot.

(Mostly trying to clear up confusion with HPC jargon - and note that for numerically heavy code modern Fortran is still faster than modern C)
permalinkparentreportreply


dfj225 2 points 2 hours ago[-]

I might agree with your distinction between upper and lowercase high performance computing, but I don't really see the two sets of problems being mutually exclusive. A program that takes days to execute might be composed of many smaller problems that execute in minutes.

But whatever, for my comment the point was to highlight that C is a good choice for code where performance matters, meaning the programmer wants to extract as much performance as possible from a given machine.

and note that for numerically heavy code modern Fortran is still faster than modern C

I think you're going to need to provide some proof for that. I don't buy that such a statement is common knowledge (at least, I don't think I've heard that claim before). Just for kicks, here's the comparison from the Computer Language Benchmark page: http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=gcc&lang2=ifc

I realize this isn't proof that C is faster than Fortran, but it is some evidence that programmers were able to write faster C code than the equivalent Fortran code for these problems with these compilers.
permalinkparentreportreply


syntax 3 points 1 hour ago[-]

It's not my distinction - it's a standard term. See top500.org for people who do High Performance Computing.

You're thinking in terms of single computer. Part of the advantage of Fortran is the integration with things link Infiniband, utilisation of vector mathematic operations [0], use of masking vectors and other esoterica. The other part comes from having a more restrictive memory model, which means the Aliasing problem is avoided [1].

The language shoot out is not a good point of comparison - it's only within the domain of heavy numerics where Fortran is faster, therefore all the other parts drag it down.

Further, there is also the practical advantage that Fortran has, in the compilers have had more work on them to produce faster numeric code. These are typically pay-ware, however (e.g. PGI fortran, or NAG fortran compilers), and so will not be in that benchmark.

LAPACK [2] is still the fastest implementations of linear algebra, for example.

I can't publish the benchmarks I have (commercial and in confidence), but I've seen differences of the order of 5-10% that were attributed (by the compiler author) to the compiler.

[0] There's native syntax for it in Fortran, and has been for ... decades. [1] http://en.wikipedia.org/wiki/Aliasing_(computing) [2] http://www.netlib.org/lapack/
permalinkparentreportreply


dfj225 1 point 19 minutes ago[-]

It's not my distinction - it's a standard term. See top500.org for people who do High Performance Computing.

Yes, I should have never used the term HPC, since it does not reference the right domain of problems / computing that I want to discuss here.

You're thinking in terms of single computer.

For this thread, yes, since that seems to be what the OP is interested in. I agree there is a pretty big distinction between writing fast code for a standard "desktop" system and a cluster of systems / supercomputer.

Further, there is also the practical advantage that Fortran has, in the compilers have had more work on them to produce faster numeric code. These are typically pay-ware, however (e.g. PGI fortran, or NAG fortran compilers), and so will not be in that benchmark.

I wonder if this is where all of the difference comes from. Granted, due to properties of the language that you mentioned (whether aliasing is an issue and so forth) it might be easier to write an optimizing compiler for Fortran compared to C.

If we only consider more common compilers, (gcc, intel, ms/visual studio), does your statement still hold? For instance, if I build LAPACK with gcc for my linux system, is there really any advantage over if LAPACK had been written in C?

I don't know too much about the operation of LAPACK, but their description states that it uses the system's BLAS functions for much calculation. On Linux systems, ATLAS is a good choice and I believe they generate C code for their routines.
permalinkparentreportreply


gmh33 11 points 4 hours ago[-]

There is plenty of work for C developers.

I've worked on projects for embedded systems in C, this is probably the largest area of work for C developers. C still dominates this domain, it might not for a whole lot longer, but for now, it does.

A lot a lot a lot of high performance computing stuff is done in C, or uses C. For instance, a cool project called SPIRAL generates high performance C code. Here's a paper by the SPIRAL people describing various techniques for optimizing C for numerical computations: How To Write Fast Numerical Code: A Small Introduction.

So, I guess to answer your question, yes. If you want to work on an embedded system, one of the easiest ways to get going is with C. If you want to be able to optimize computation by taking advantage of registers, optimal cache use, limiting memory allocations, you may want to go with C.
permalinkreportreply


dsquid 2 points 4 hours ago[-]

Good for you: this is a normal part of the maturation process of a programmer/software engineer/whatever. In my experience, you're already ahead of 80% of the coders out there.

You're also, IMHO, going about this in the right way: exploring and learning on your own, expanding your "sphere of understanding" as you go.

I had a similar experience when I went back to x86 Assembler from from MFC/ATL: I know what every line of code does, and it's mine..all MINE! Glorious, though there are definitely two sides to that coin.

Another big step from where you're at comes from stepping back from this all experience and picking out trends and "lessons learned" in the broader sense. For example, think about the frameworks, the problems they solve, how they solve 'em...realize there is no silver bullet, just an endless series of tradeoffs (few of which are demonstrably "Right"). This will give you a new perspective on the religious wars others get into.

Lots of fun down this path you're one...and even more if you decide to hop into the "dark side" of management!
permalinkreportreply


spinkham 6 points 4 hours ago[-]

C will definitely last. Eventually something like Go or D or some other C incremented language will take off for systems programming, but for now C is still the king.

I love Ruby, and it beats the crap out of C for text wrangling. And there's a whole lot of text wrangling to be done out there, but Ruby isn't right for every problem.
permalinkreportreply


Rusky 2 points 4 hours ago[-]

I have the same impression of C. I started with simple games and websites, using high-level scripting languages. I also like Haskell and Erlang, but C is great. It's relationship with assembly is exactly why it's so great. There's a lot of boilerplate if you do higher-level things, but if you're writing low-level stuff (kernels, embedded, etc.) it's beautiful.
permalinkreportreply


dwchandler 75 points 4 hours ago[-]

Welcome back. :) You aren't going mad. Almost every concept embodied by newer languages was well known decades ago and have more to do with how you think about the problem domain and translate it into code. Newer languages have the advantage of allowing a more direct translation of some ideas into code, as well as doing away with boilerplate. This often comes at a price of being forced into a paradigm and/or losing control.

And here's something... I think I've become a better OO programmer after going back to pure C. It's made me rethink what I was gaining from OO, how I could attempt the same gains in C, and what OO I was glad to leave behind. My conclusion: OO solves some problems very well indeed, but the common OO mindset these days is somewhat insane.

So do I use C for everything now? Not at all. But there's a surprisingly large class of problem that I do tackle with C. Use the best language for the job at hand, with C as a viable option.
permalinkreportreply


Chridsdude 1 point 24 minutes ago[-]

am i the only one who uses python?
permalinkparentreportreply


turbov21 8 points 1 hour ago[-]

I don't disagree with you at all, but I must say, it's a little unnerving when the C guys start sounding like LISP guys.
permalinkparentreportreply


dwchandler 6 points 1 hour ago[-]

Ha! No LISP for me so far. Maybe it's the Haskell, or the more functional aspects of Python & Ruby. But really I think it's coming to an understanding of core problems and attempted solution in software development. Managing complexity, decreasing coupling, functional cohesion over temporal, etc. All of this I first learned many years ago and none of the principles have changed. It's all true for C, F# or assembler.
permalinkparentreportreply


prockcore 9 points 1 hour ago[-]

but the common OO mindset these days is somewhat insane.

Indeed. The OO "abstract every fucking thing" mindset drives me crazy.

An OO programmer designing a car would build a giant monstrosity that allowed you to replace the steering wheel with a blender if you wanted. But the desire to make every single component of the car generic and interchangable has led to a car that no one wants to drive.
permalinkparentreportreply


munificent 14 points 1 hour ago[-]

A shitty OO programmer designing a car

FTFY. People can write shit code in any paradigm. Powerful languages that let you do a lot with a little code also let you do a lot of damage with a little code. C only solves that in the sense that giving a madman a spoon instead of a sword makes him a safe person.
permalinkparentreportreply


cfedde 8 points 1 hour ago[-]

It's really hard to do good design of any type. OO is no exception. And programing language choice has nothing to do with it. It is my assertion that software projects succeed or fail despite the programming languages used.
permalinkparentreportreply


tommy255 0 points 1 hour ago[-]

The problem is that OO actively encourages you to act in insane ways.
permalinkparentreportreply


jbs398 1 point 30 minutes ago[-]

It really doesn't. It may lower the barrier to doing certain insane types of things, but you can say the same thing of any simplifying abstraction. Take the entire hierarchy of abstractions that underly that OO language (the C that it's probably written in, the machine code that translates into, the microcode running on the CPU, the CPU itself, the physics on which transistors depend, etc...) and you'll find that there are "insane" things that are made easier because of each and every one of them. There isn't anything inherent about OO that's any worse than that, the real problem is that people don't understand the abstractions that they're using (some people also abuse them because they understand the abstractions too, but that's a different story), and because of this they make bad decisions and don't realize it until they've created a monster.

Abstractions are great, just know why/how they're broken when you use them :-)
permalinkparentreportreply


tommy255 2 points 17 minutes ago[-]

But that's my point. If the vast majority of OO code looks exactly like you and I know it looks, then that's pretty good evidence that there is something wrong with OO itself.

There are lots of other evidences: continuing argument and restlessness about "unresolved" issues in OO such as single- vs. multiple-inheritence, checked- vs. unchecked-exceptions (and the whole quagmire of exceptions at all), how best to handle and implement generics. Not to mention the even bigger divide behind stances like dynamic and static typing, duck-objects, etc.

Add to all that the fact that "proper" encapsulation is almost always a fairy tale, that no one "really" does const-correctness right, etc, etc.
permalinkparentreportreply


lispnik 1 point 50 minutes ago[-]

Please elaborate.
permalinkparentreportreply


tommy255 3 points 39 minutes ago[-]

Conflating functions and the data they operate on is not always a good idea, but in OO, everything is an object. State is often hidden in objects, and side-effects are rampant.

Additionally, every implementation of OO has its serious flaws. The templating system in C++, for example, is a nightmare. Taken alone, these are just "implementation problems" and don't damn the entire approach, of course. But after all these years, we still don't have a complete system for dealing with objects, as if we are feeling blindly, heading toward something we sense as "the OO Light," not sure if with each step we are actually getting closer or heading over the edge of a cliff.

I don't really have a solution. I'm part of the problem.
permalinkparentreportreply


ericmoritz 2 points 22 minutes ago[-]

I've started using mindset that if I don't need to be carrying state around with my functions, there's no reason for me to use objects.
permalinkparentreportreply


tommy255 1 point 16 minutes ago[-]

YAY!
permalinkparentreportreply


dwchandler 13 points 1 hour ago[-]

I don't think that's true. I think it's the communal insanity that began with the pattern book and people not really grokking it, but applying patterns blindly. Somehow that led to a runaway train of burning stupid.

But step outside the bizarro world and OO languages can be very nice. You can find some incredibly well written OO code, and it's just a pleasure.
permalinkparentreportreply


tommy255 2 points 51 minutes ago[-]

I've spent most of the last 15 years writing OO code, in C++, in Java, in Python and Ruby. There is something fundamentally broken about objects and what it inspires people to do when writing code.

I'm not saying that it's impossible to write "good OO code." I'm just saying that I'm not sure the benefits of OO really outweigh its disadvantages, even after all this time.
permalinkparentreportreply


dwchandler 2 points 1 hour ago[-]

I've seen enough of other people's C++ to know that the world if chock full of shitty OO programmers. Otherwise smart people sit around thinking of how they can add more layers until it's far too complex.

You can botch C so bad it'll give you a headache, but most of the people who would do so are using Java or C++ instead.
permalinkparentreportreply


shazb0t 1 point 18 minutes ago[-]

Otherwise smart people sit around thinking of how they can add more layers until it's far too complex.

I have seen this time and time again. Things that should have taken 20 mins to code end up taking months... I pitty tha foo who has to maintain it. Oh yeah, that's me =(.
permalinkparentreportreply


dan_cooper 0 points 1 hour ago[-]

Bunny Rabbits, Satan, Cheese and Milk. I like meat. http://www.youtube.com/watch?v=eIF4xTSr6fA

It's more like giving a two year old either a shotgun or a nuclear bomb, then asking him to go hug his older sister. C is like a koan, only then you die.
permalinkparentreportreply


plainsane 2 points 1 hour ago[-]

i cant say i have become a better oo dev because i revisit c on a regular basis.

i will say its taught me a stronger appreciation for oo provided by c++ and much more so for the oo provided by java and python.

c++ has oo issues, but i can live with them. i find my self always writing pseudo c in a c++ compiler. i just cant shake the crack called "compile time c++ features"...i like operator overload and single inheritance that c++ provides...flawed, but still allows me to express my intent in my c++ code better then my c code (and i have to switch between the 2 on a regular basis).
permalinkparentreportreply


sephiroth2k -3 points 1 hour ago[-]

Java needs to die.
permalinkparentreportreply


plainsane 0 points 35 minutes ago[-]

hahahahah, i fucking hate it. i only work with it when my job depends on it.

my boss only gives me java stuff when its mission critical or nobody else can figure out the issue, the rest of the java work goes to interns. god bless those under paid sum bitches.
permalinkparentreportreply


lake-of-fire 6 points 4 hours ago[-]

Totally agree, with each of your paragraphs there.
permalinkparentreportreply


arnedh 5 points 4 hours ago* [-]

One good thing about C these days: less conversion when you adapt it to OpenCL or CUDA, and run the fractal in the GPU (240 cores) instead. There is a ready example in the ATI Stream SDK (Mandelbrot), and more code to be found elsewhere.
permalinkreportreply

OMouse comment score below threshold[+] (2 children)


pipocaQuemada 5 points 4 hours ago[-]

From what I understand, it's common to do your parallelism + distribution in Erlang, and to use C and the foreign function interface to do the actual "work" of the algorithm.

I think that there's a place for C, but using C in combination with other languages is good. I think that writing an entire program in C is probably premature optimization.
permalinkreportreply


ryeguy 5 points 4 hours ago[-]

This is even easier in Erlang now that NIFs are around. You can basically create plugins/extensions in C and call them directly from Erlang.
permalinkparentreportreply


mpeg4codec 7 points 4 hours ago[-]

C is great, and like you say, the fact that you can practically see the machine code that will come out of it is something I frequently miss in other languages.

Interesting background, I too cut my teeth on rom hacks. Maybe that's what gives us our love of the low level :)
permalinkreportreply


davebrk 3 points 4 hours ago[-]

Why didn't you try writing that in Java (I'm serious).
permalinkreportreply


buddhabrot [S] 9 points 4 hours ago* [-]

I don't know, I never touch Java anymore unless I need to program a cross-platform UI.
Java just got boring for me. I also have a lot of negative feelings on Java because it was used as a web-application language at my company and I can't understand why people would want to use it for that. I have to say I don't understand the "place" Java has in the language spectrum anymore.
permalinkparentreportreply


MarshallBanana 7 points 2 hours ago[-]

Java is an average language for average programmers to write average programs in.
permalinkparentreportreply


lllama 5 points 3 hours ago[-]

Well, for instance you could have used Java to implement this scenario you are describing here.

It has near C speed for most things, a good threading and locking API (since Java 1.6), and for the things that would be hard to do with it (manipulating byte arrays directly for instance) it has good support for letting you use C for that.

On top of that the Java framework has some very good features for performance profiling.
permalinkparentreportreply


gleapsite 15 points 4 hours ago[-]

Of course C will last. Its used quite extensively in embedded electronics. If you wanna have some fun writing C go pick up an arduino dev board, download avr-gcc (or use arduino's built in software) and happy hacking.
permalinkreportreply


spinkham 3 points 4 hours ago[-]

wrt54gl or other openwrt platforms and the beagle board are also a fun places for embedded C programming with a number of special features.
permalinkparentreportreply


rufius 24 points 4 hours ago[-]

C will last till something sufficiently low level and flexible is developed to replace it. At the moment, that seems to be of little concern to people so we probably won't see an evolution from C for a while.

That said, the software development world will continue to grow in higher level languages.

There's interesting jobs in C, but they're hard to come by. I work in operating systems and work mostly in C and C++. A lot of embedded systems groups use C among other languages like Forth or Ada. In my experience, C/C++ jobs tend to pay better than Java/C#/Ruby jobs which is also a plus if you enjoy C and can put up with its quirks :).
permalinkreportreply


HeroOfCanton 4 points 1 hour ago[-]

I have a fantastic job where the only language I work in is C. I couldn't be happier! :D
permalinkparentreportreply


ffualo 4 points 39 minutes ago[-]

Wow! Do you mind if I ask you some questions? I am moving from Python and R to C for speed. I develop tools mostly on my own time to use at work, until I can justify the extra time at work.

Do you develop in an *nix environment? Do you use a unit testing framework? What's your build cycle like? Is your development build cycle different than your release build cycle?

I ask because I am trying to move into the realm of packaged and released C programs. I use autoconf now, with a custom simple Makefile for development (because waiting for autoconf to update takes too long). I'm curious how professional software development in C happens - there is so little written about this on the internet.

Thanks!
permalinkparentreportreply


HeroOfCanton 1 point 9 minutes ago[-]

I write firmware. Right now, I am mostly working with ARM7 processors, but I've also worked with Cypress USB chips and Xilinx FPGAs.

I use 32bit Windows XP, and I use Keil tools for ARM development.

Generally all my work is a component of the overall development of a physical electronic device, the software (firmware) doesn't really get released by itself. So the dev build cycle is pretty relaxed, private releases at certain milestones (usually feature-centric) building to a public "release" when the product launches, and a certain period of maintenance afterwards.

I did *nix-based packaged C programs in college, and used emacs(and eclipse), gcc and a Makefile. Keil tools uses an ARM proprietary compiler and has a wizard-type windows to configure the build options for compiling/linking etc.
permalinkparentreportreply


fluffy_543 1 point 2 hours ago* [-]

In my experience, C/C++ jobs tend to pay better than Java/C#/Ruby jobs which is also a plus if you enjoy C and can put up with its quirks :).

I'm currently looking for a job and I noticed that low level C/C++ job-postings frequently require previous professional experience in higher-level languages like C#/Java/Python and so on. Low-level work can mean a higher career level.
permalinkparentreportreply


[deleted] 4 hours ago[-]

[deleted]
permalinkparent


Catfish_Man 1 point 2 hours ago[-]

CoreFoundation.framework on OSX is mostly written in C (among many others).
permalinkparentreportreply


cheese_wizard 2 points 2 hours ago* [-]

I work on factory equipment (Machine Vision Inspection systems to be precise). We use plenty of C. This is not embedded nor kernel related. Just lots of routines that talk to hardware from the GUI, which is written in a goofy subset of C and C++. Basically POF, but using C++ streams, STL, and such to make life easier. But we're all used to it, and we're successful.
permalinkparentreportreply


pspda5id 2 points 3 hours ago[-]

Lies, I use C and C++ at work for Windows applications work. And Objective-C for iPhone games.
permalinkparentreportreply


darth10 1 point 1 hour ago[-]

MFC or MSVC++ ... NOT PLAIN C
permalinkparentreportreply


FlyingBishop 1 point 1 hour ago[-]

iPhone is embedded.
permalinkparentreportreply


ferna182 3 points 2 hours ago[-]

we use C++ for iphone.we just write the platform specific parts on Objective C (touchscreen, sound, etc) but the whole application is written in C++. in fact, we do 95% of the development + debugging on a Windows PC and we use Xcode on a mac and iphones when testing performance, input methods, interrupts, connectivity, etc. and, since we obviously already written a common library that handles all the platform specific stuff, there's almost no need for us to write ANYTHING in Objective C. we just use the macs to compile our projects.
permalinkparentreportreply


ahminus 2 points 3 hours ago[-]

And pretty much every video game PC and console video game. Which is like, probably 50% of all the code written in the world.
permalinkparentreportreply


kefeer 10 points 3 hours ago[-]

C++ is not C.
permalinkparentreportreply


ahminus 6 points 3 hours ago[-]

Eh, lots of "C++" code bases are really C+-.

I use classes (when I actually use them) as glorified structs.

I rarely use templates, no operator overloading, and my class hierarchies are rarely more than 2 layers deep. I'm also not writing against an application framework, typically.

Any knowledgeable C programmer has absolutely no problem grokking this type of C++. And all the C++ programmers I know have no problem reading C codebases (like the kernel and device drivers, etc).
permalinkparentreportreply


princeofpeas 1 point 1 hour ago[-]

what he means is don't sully the good name of C by roughly equating its power with your C+-
permalinkparentreportreply


ahminus 2 points 47 minutes ago[-]

Yes, I know C is not quite as powerful as "C+-". I didn't mean to imply otherwise.
permalinkparentreportreply


princeofpeas 1 point 43 minutes ago[-]

you're aware that the final product is machine code right?
permalinkparentreportreply


ahminus 2 points 41 minutes ago[-]

I'm sorry, but how is that relevant?
permalinkparentreportreply


radarsat1 5 points 3 hours ago[-]

Also most audio processing code, like soft synths etc. Anything that requires real-time interaction pretty much.
permalinkparentreportreply


capt0bvious 15 points 3 hours ago[-]

Tell that to the C programmers working on the electronic healthcare claims processing apps where I work.
permalinkparentreportreply


super__mario 1 point 1 hour ago[-]

This sounds like a perfect opportunity to use something slightly higher level like Java. C is just too low level for something like claims processing. Yikes.
permalinkparentreportreply


flogic 9 points 3 hours ago[-]

I find that rather horrifying.
permalinkparentreportreply


goggles2 -2 points 3 hours ago[-]

Didn't know there were any paying kernel development jobs out there. There are probably jobs for writing device drivers though.
permalinkparentreportreply


yoda17 1 point 2 hours ago[-]

I don't know what the current statistics are, but I read that something like 97% of all embedded systems (a market that dwarfs the PC arena) run with roll your own OS as opposed to a COTS OS like VxWorks or PSOS.

Yes, this means true OS functionality like you would find in a book on operating systems like tasking, memory management, I/O etc with very little GUI work, I think anymore all GUI work is done through IP and a web browser peeking into memory locations and doing data processing elsewhere (that most people think of when you say operating system).
permalinkparentreportreply


buddhabrot [S] 4 points 3 hours ago[-]

You'd be amazed: http://apcmag.com/linux-now-75-corporate.htm
permalinkparentreportreply


iamjack 14 points 3 hours ago[-]

Are you kidding me? 75% of Linux is written by paid developers (there was a reddit post before). I'm one of them and I have a lot of kernel coworkers. And that's just Linux. Working for Apple or Microsoft or Sun (Oracle?) gives you a shot at their kernels too.

I'm not sure why you don't count device driver writing either, that's definitely kernel level C. Regardless though, algorithms are always improving, always changing. Schedulers become more efficient, memory managers more detailed. There's still a lot of work to do in OS design and maybe even more in making our current OS systems suck less.
permalinkparentreportreply


dozerl 1 point 1 hour ago[-]

How did you get into Linux kernel development with a company? That's what I want to get into. Do you have any pointers for someone wanting to get in to that field?
permalinkparentreportreply


goggles2 0 points 2 hours ago[-]

I'm not sure why you don't count device driver writing either,

Oh, you mean: why don't I count writing drivers as part of kernel development. Are drives part of a kernel which dynamically loads drivers? I guess I figured there was enough distinction there to consider them separate.
permalinkparentreportreply


inotocracy 4 points 4 hours ago[-]

Its all about the right tool for the job. If generating a fractal in C is quicker, then by all means write it in C. That doesn't necessarily mean you need to write tons of boiler plate for every application you create, or use C for everything. Also-- would you mind posting the source code for your multithreaded fractal generator? :) Would be great to see your implementation in each language you attempted.
permalinkreportreply


buddhabrot [S] 5 points 4 hours ago[-]

This is my (very amateuristic C code, it doesn't use the mutex lock hierarchies because I haven't got the bugs out of that yet. The haskell code is at home I'll post it in a separate post. Erlang is loose scraps, I programmed mandelbrot in it parallelly and quickly figured it was too slow.

http://pastie.org/795264
permalinkparentreportreply


rjett 1 point 18 minutes ago[-]

I learned something by checking out your code. I used to write a lot of PHP and I was a very big fan of GD. I didn't know that it was accessible in C. It makes sense though. Next time I get some free time I'm going to start tinkering with GD in C! Thanks man!
permalinkparentreportreply


select 1 point 34 minutes ago[-]

Could you make us a wallpaper too? :-) I like this colorscheme: http://upload.wikimedia.org/wikipedia/commons/f/f1/Buddhabrot-deep.png
permalinkparentreportreply


inotocracy 1 point 4 hours ago[-]

Looks good to me! Thanks. Even though its all loose scraps, I'd still be curious to see what the implementation may look like in other languages. I love reading other people's code, its very fascinating :)
permalinkparentreportreply


buddhabrot [S] 1 point 4 hours ago[-]

This is the haskell btw, it's slow because it's not so well programmmed. I was also in the middle of refactoring it to Map so it might look odd. http://pastie.org/795329
permalinkparentreportreply


xixor 18 points 4 hours ago* [-]

Personally, I wouldn't be too quick to cast away C++: remember, it wasn't C++ you didn't like, it was the MFC, don't blame C++, MFC was horrid.

C++ is compatible with the C99 standard so you can write C in C++ and still have access to parts of C++ that really save a lot of time without having to remember that much (i.e. classes std::vector, std::list, std::map). Seriously, who wants to roll their own linked list or hash table anymore when there are much more interesting things to work on? You don't have to go whole-hog into OOP design patterns and such, you can still program in the functional style of C, but take the parts of C++ that can really save you. C++ code is darn fast too.
permalinkreportreply


krum 17 points 4 hours ago[-]

C++ is not compatible with C99.
permalinkparentreportreply


tgbyhn 3 points 3 hours ago[-]

C++0x is just a few macros away (or even less) from C99 compatibility for the vast majority of programs.
permalinkparentreportreply


krum 6 points 3 hours ago[-]

Don't you mean C++1x? 8D
permalinkparentreportreply


fwork 2 points 1 hour ago[-]

No one ever said the numeral indicated by the x was in decimal.

/me points at his January 200A calendar
permalinkparentreportreply


bluGill 2 points 48 minutes ago[-]

I think you mean January 7DA calendar.
permalinkparentreportreply


wheeman 2 points 1 hour ago[-]

Where'd you get that January 8202 calender?
permalinkparentreportreply


fwork 4 points 1 hour ago[-]

Lying in a trash bin in January 8203, duh.
permalinkparentreportreply


nemtrif 12 points 4 hours ago[-]

C++ is compatible with the C99 standard

You probably mean the C89 standard
permalinkparentreportreply


buddhabrot [S] 4 points 4 hours ago[-]

Yes I didn't want to go to deep in the C/C++ debate but I'm also planning on learning C++ again. Although I have to say I got influenced by functional languages to think less in object hierarchies, I think a lot of areas of a compiler could be written more elegantly in C++.
For instance the hierarchy in AST's feels "simulated" when it's written in plain C.
permalinkparentreportreply


goggles2 4 points 3 hours ago[-]

I think C++ is alright if you can stick like superglue to a restricted subset of the language.

Maybe the world could use a "Strict C++ subset" renaissance instead of C++0x (or C++xx, as the case may be). Didn't someone once say,

"Imprisoned in every large programming language a smaller one is wildly signaling to be let out."

? (Apologies to Cyril Connolly.)
permalinkparentreportreply


yoda17 2 points 2 hours ago[-]

Can you say MISRA?
permalinkparentreportreply


Tommah 1 point 3 hours ago[-]

I think a lot of areas of a compiler could be written more elegantly in C++

If you really mean a compiler and not an interpreter, my advice to you would be to write it in a higher-level language with garbage collection. (Maybe read this: http://flint.cs.yale.edu/cs421/case-for-ml.html ) A compiler just takes in program code and produces machine code, so there's no need for it to be super-super-fast. Save C for when you really need it. I've used C to write some AIs for simple board games, and there it pays off, because you end up calling functions millions or billions of times.
permalinkparentreportreply


zid 4 points 1 hour ago[-]

Having a slow compiler is like being addicted to drugs.

Every thought you have is overshadowed by how it might need you to recompile. It hangs over you like a cloud. It's a persistent nagging in the background, that you had better do this, or do that, for fear of having to do an extra recompile.

A fast compiler isn't just a neat tool, it's a liberator.
permalinkparentreportreply


bluGill 1 point 45 minutes ago[-]

I agreed. Though it is more than just the compiler. By watching the process monitor I was able to determine that 75% of my build time is taken by the build system, and only 25% by the compiler. (Now if I just understood how the build worked well enough to replace it - not to mention the build system only knows how to feed 1 core)
permalinkparentreportreply


ithika 2 points 1 hour ago* [-]

With most heavy codebases it isn't the compiler that's the problem. Crufty, recalcitrant make systems which require you to blow everything away and rebuild from scratch, or slow linkers, or endless file munging with perl scripts, or systems built from several code bases that never quite work together: these are what slow me down more than the compiler itself.

Edit: Obviously this is my experience, but I think it doesn't take very long before an environment has built itself up so that production of .o's is not the aspect that needs optimised. YMMV.
permalinkparentreportreply


zid 1 point 49 minutes ago[-]

Obviously you've never used C++.
permalinkparentreportreply


TiltedPlacitan 1 point 29 minutes ago[-]

In my experience, build times under compilers that don't have pre-compiled headers support are dominated by the compilation of headers. Stripping #includes, and particularly #includes within header files themselves speed things up a great deal.
permalinkparentreportreply


ithika 1 point 42 minutes ago[-]

This is true in the sense you mean it. I have used C++ for a company but I ... uh ... I didn't get to compile it. Yeah, you read that right. They would email me a small subset of source files that had a problem and got me to "fix" them. These files couldn't be compiled on their own.

I recently heard they were looking into something called "source control" but I don't know how that went...
permalinkparentreportreply


zid 1 point 39 minutes ago[-]

How was that even possible? >_<

One of the key reasons I don't like C++ is that it's impossible to find definitions, or know what an operator is doing, etc etc etc just from a snippet of code. (This is also exactly the reason why it compiles so slowly).
permalinkparentreportreply


ahminus 4 points 1 hour ago[-]

A compiler just takes in program code and produces machine code, so >there's no need for it to be super-super-fast.

/me stares blankly.
permalinkparentreportreply


Tommah 1 point 1 hour ago[-]

Did you have a point?
permalinkparentreportreply


ahminus 1 point 44 minutes ago[-]

Time compiling Firefox or the linux kernel on your machine. Or maybe any number of Java codebases. Particularly crappy bloated Java codebases with crappy dependencies.
permalinkparentreportreply


addmoreice 3 points 1 hour ago[-]

"so there's no need for it to be super-super-fast"

try compiling a multi-million line code base and tell me how you feel on that.
permalinkparentreportreply


Tommah 1 point 1 hour ago[-]

This guy isn't trying to replace gcc; he just wants to write a simple compiler.
permalinkparentreportreply


addmoreice 1 point 25 minutes ago[-]

"A compiler just takes in program code and produces machine code, so there's no need for it to be super-super-fast"

this seems to not be a statement referring to the specific situation (which i agree with you on, hence why MY compiler is not terribly quick...for now, i hope) it seems to be a general statement about compilers. ie, they do not need to be super fast.

I was simply pointing out that without a zippy compiler some issues make development styles nearly unacceptable. an example: When my compiler can no longer compile my OS image/programs quickly enough for me to do iterative build cycles/JIT loading I will need to upgrade the performance of my compiler.

as for 'build it in a higher level language' yes, oh god yes! do this. you will save yourself many many many hours of pain. I can't do this for my JIT (and since my os is written in the same language well...i might as well build just two areas of failure instead of three >.< hehe).
permalinkparentreportreply


Tommah 1 point 25 seconds ago[-]

It obviously depends on my definition of "super-super-fast" ;)
permalinkparentreportreply


dr-steve 2 points 2 hours ago[-]

Heretical thought: nonpersistent programs don't need to care about memory leaks.

Compiler starts, it compiles, it uses memory, it finished the module, all of the memory is recycled by the OS. In fact, it may be argued that a "use it and lose it" compiler is more efficient than a "manage the FSL" compiler for almost everything it compiles.

Only persistent systems need to worry about resource recycling as they are the only systems for which monotonically increasing resource utilization can have adverse system-wide impact.
permalinkparentreportreply


Tommah 2 points 1 hour ago[-]

That's a good point. But see addmoreice's comment above :)
permalinkparentreportreply


ablakok 4 points 3 hours ago[-]

I don't necessarily want to promote this, but C++ supports a lot of functional programming constructs, especially if you use the boost C++ libraries. The syntax is cumbersome (lots of templates), but you can arguably write better C++ code after experience with functional languages, and you can write faster functional code using C++. Except I don't think there are any first-class continuations.
permalinkparentreportreply


jimbokun 3 points 1 hour ago[-]

Why are you hesitant to promote functional programming constructs in C++?
permalinkparentreportreply


load more comments (2 replies)


load more comments (1 reply)


load more comments (6 replies)

Andy Tanenbaum hasn't learned anything

http://harmful.cat-v.org/software/andy_tanenbaum

apache reverse proxies

http://www.apachetutor.org/admin/reverseproxies

working harder not smarter with redhat backporting apache

http://www.redhat.com/security/updates/backporting/?sc_cid=3093

use mod proxy ajp

(12:44:41 PM) The topic for #rhel is: Red Hat Enterprise Linux (RHEL) Discussion | Stable: 5.4, 4.8, 3.9 | EOL: 6.2E, 2.1 | pastebin: http://fpaste.org | related channels: #fedora, #centos, #rhn, #rhn-satellite, #spacewalk. Non RH extra package sites are http://fedoraproject.org/wiki/EPEL, http://rpmrepo.org/RPMforge/, http://rpmfusion.org and of course http://elrepo.org | Due to spamming only registered have voice
(12:45:03 PM) gws: yum says zlib is installed, and httpd complains it can;t find zlib
(12:45:10 PM) gws: during compile
(12:45:13 PM) gws: ;)
(12:45:23 PM) Evolution: gws: 'yum install httpd' works fine
(12:45:34 PM) Evolution: gws: having said that, zlib isn't the same as zlib-devel
(12:45:43 PM) gws: nope security scan says 2.2.8+ and redaht 4 has not that
(12:45:52 PM) rigeld2: gws: learn about backporting
(12:46:07 PM) gws: plus ill be damned if i can get tomcat connectors and opensslk+ too
(12:46:08 PM) rigeld2: gws: http://www.redhat.com/security/updates/backporting/?sc_cid=3093
(12:46:10 PM) gws: for damn sec scan
(12:46:20 PM) Evolution: gws: your security scan is relying on version numbers. which is idiotic at best.
(12:46:30 PM) gws: yep corporate in texas is stupid
(12:46:59 PM) bip left the room (quit: "Lost terminal").
(12:47:15 PM) rigeld2: gws: Debateable :) I know an ex-corporate security guy (worked for Liondel) and they didn't use version numbers.
(12:47:26 PM) rigeld2: gws: Simple fix - don't report version numbers to scanners.
(12:47:46 PM) gws: oow, how do I do that?
(12:48:03 PM) rigeld2: gws: in apache? trying to remember the string inhttpd.conf
(12:48:24 PM) gws: ok I was able to compile apache on another redhat 4 box, I just did yum isntall zlib-devel, should apache pick itup now?
(12:48:37 PM) delhage: ServerTokens Prod
(12:48:42 PM) gws: I thought it was an apachectl option or something
(12:48:43 PM) gws: hm
(12:48:49 PM) rigeld2: delhage++
(12:48:59 PM) aitrus: ServerTokens
(12:49:03 PM) aitrus: damnit, bork
(12:49:04 PM) rigeld2: gws: Change your ServerTokens line in httpd.conf, reload httpd and win
(12:49:22 PM) gws: looking..
(12:50:07 PM) makfinsky: rigeld2: Thanks for link!
(12:50:19 PM) rigeld2: makfinsky: ... which link? :p
(12:50:29 PM) gws: ah hah!
(12:50:33 PM) gws: now set to Full
(12:50:43 PM) makfinsky: The backporting one. Explaining that is a pita.
(12:50:48 PM) rigeld2: makfinsky: Ah.
(12:51:03 PM) rigeld2: makfinsky: I'd lmgtfy but no going to :p
(12:51:34 PM) makfinsky: Hehehe.
(12:51:54 PM) makfinsky: I had been using riel's presentation re: kernel patches from last year's summit.
(12:52:42 PM) makfinsky: However, the jump from kernel to apache was too great for some customers...
(12:53:20 PM) gws: wow you guys are good it was zlib-devel
(12:53:24 PM) gws: now apache compiling
(12:53:42 PM) rigeld2: gws: But you don't need to compile apache...
(12:53:46 PM) gws: well concept of backporting yes but betting managment to BELIEVE it ya
(12:53:52 PM) Evolution: gws: seriously. that's the wrong way to go about fixing security issues.
(12:53:57 PM) makfinsky: Some folks like to re-invent the wheel.
(12:54:09 PM) rigeld2: gws: Have fun managing keeping up with updates for all the packages you compile
(12:54:12 PM) gws: ok so what should I do then?
(12:54:15 PM) rigeld2: gws: Oh, and what they break.
(12:54:17 PM) makfinsky: gws: They are paying for it already.
(12:54:17 PM) rigeld2: gws: Con'
(12:54:22 PM) aitrus: get a list of CVEs that they are concerned about
(12:54:32 PM) rigeld2: gws: Don't compile shit, check CVE
(12:54:33 PM) aitrus: and match those up with RH annoucements
(12:54:38 PM) gws: yeah well I got it working on our other int environment, but it did take compile openssl, then apache, then compiel modjk
(12:54:43 PM) rigeld2: 's with redhat, and watch RHbackport the fixes.
(12:54:48 PM) gws: cve?
(12:54:59 PM) ***Evolution facepalms
(12:55:02 PM) gws: oh vulnetability report?
(12:55:06 PM) gws: ok ok I being to see
(12:55:06 PM) Evolution: yes.
(12:55:09 PM) makfinsky: Evolution: Cluebat?
(12:55:14 PM) Evolution: makfinsky: yesplease.
(12:55:15 PM) nirik: http://en.wikipedia.org/wiki/Common_Vulnerabilities_and_Exposures
(12:55:18 PM) rigeld2: gws: Yeah, well, thats the wrong way to do it. Unless, like I said, you like managing all those packages.
(12:55:21 PM) riel: makfinsky: many security folks are beratungsresistent
(12:55:38 PM) gws: coporate got some outfit, than did scan and gave us big spreadsheet
(12:55:44 PM) makfinsky: riel: :) I know.
(12:55:55 PM) crobinso [n=crobinso@c-24-62-100-20.hsd1.ma.comcast.net] entered the room.
(12:56:00 PM) makfinsky: That outfit wasn't worth the money they got paid.
(12:56:12 PM) Evolution: gws: yep. that's how it generally works. then you produce your own, point by point telling them why they need to go pound sand up their ass.
(12:56:15 PM) gws: as are msot things our texas masters do, and they wonder why stock under 1$
(12:56:23 PM) makfinsky: I've educated all the security folks I know if they didn't already understand it.
(12:56:29 PM) Evolution: security audits are loads of fun.
(12:56:49 PM) gws: ok cool so I should 1 install apache binary 2 install openssl binary? 3 isntall mod jk?
(12:56:53 PM) riel: gws: even more fun if you do your analysis and ask the security folks if they can come up with a list of CVEs :)
(12:57:11 PM) gws: if I do so.....does redhat have backported openssl and modjk?
(12:57:14 PM) riel: chances are half of the security consultants out there won't have any idea what you talk about when you ask for CVEs
(12:57:15 PM) maxamillion: rigeld2: bleh, I was about to leave for class and then I get a jabber message from norma
(12:57:15 PM) gws: LOL
(12:57:18 PM) rigeld2: gws: If the security report doesn't include CVEs, its a lot more annoying, but you can take the CVE's, match to RH fixes, and tell them its fixed
(12:57:21 PM) Evolution: gws: mod_jk is ancient. prxy_ajp is the new hotness.
(12:57:22 PM) rigeld2: gws: ... Yes.
(12:57:30 PM) rigeld2: maxamillion: go to class
(12:57:41 PM) rigeld2: gws: Seriously, read the damn backporting page.
(12:57:43 PM) Evolution: gws: you can also query the bot here for particular CVEs
(12:57:43 PM) gws: I know but no one at work in dev uses proxy ajp and if I do that, then I gota make it work.
(12:57:59 PM) maxamillion: rigeld2: in a sec, I still got like 2 and a half minutes
(12:57:59 PM) gws: I myself would like to use mod_proxy_ajp
(12:58:12 PM) Zathrus: gws: we've been over this with you before.
(12:58:30 PM) gws: also in production [yay at at&t managed services!] the modjk is used so boss says make ti look as prod
(12:58:30 PM) rigeld2: Make sure I'm not retarded - importing a pem file into a java keystore is the wrong way to go about things, isn't it?
(12:58:31 PM) ***Zathrus thought the nick was familiar.
(12:59:05 PM) Evolution: rigeld2: I didn't think so.
(12:59:09 PM) gws: ok I will setup side environemtna nd do it with binaris and mod_proxy_ajp
(12:59:10 PM) Evolution: why would that be bad?
(12:59:14 PM) makfinsky: gws: Getting support of rmod_jk requires RH App Stack which is $7k per system per year. proxy_ajp is included in RHEL.
(12:59:44 PM) gws: oh no shit, I can just yum it?
(12:59:44 PM) rigeld2: Evolution: ... trying to figure out why I keep getting "javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated" on my tomcat box, when all the involved certs are in the keystore
(12:59:55 PM) gws: I am doing thing hardway
(12:59:59 PM) rigeld2: gws: ... read the damn backporting document
(1:00:07 PM) gws: ok
(1:00:08 PM) rigeld2: gws: No shit sherlok. Thats what we've been saying
(1:00:27 PM) aitrus: hahahahaahhaha
(1:00:47 PM) aitrus: rigeld2: are the CA certs in the truststore?
(1:00:58 PM) rigeld2: aitrus: ... keystore != truststore?
(1:01:03 PM) aitrus: right
(1:01:13 PM) Evolution: gws: you're also doing it in a fashion that's going to add immense overhead to your life later on for updates.
(1:01:23 PM) aitrus: keystore holds client / server certs, truststore holds CA certs
(1:01:24 PM) Evolution: gws: this is EXACTLY the reason people use RHEL.
(1:01:31 PM) Evolution: the hard work is done for them by other people.