Heya! Time to check up on the credentials of /prog/. Also, feel free to brag your heart out!
The idea is that you post the languages you have done non-trivial (add trivial if you wish) projects in. An estimate on the number of lines of code might be useful too. I'll start:
Non-trivial:
PHP - Built my own lite CMS (approx. 400 lines)
Python - Currently making a file tagging/rating app (500 lines)
C - Plugin for Etheral (1000+ lines, mostly Ethereal parameters)
Trivial:
Erlang - Built a Linda Tuplespace (school, maybe 50 lines)
Java - Varios crap, the most advanced being a simple board game (school, 200 lines)
Haskell - Various crap, made an adventure game (school, 300 lines)
That's about it for me. Now lets see what Gods of programming we've got in here!
>>13
sometimes I really wonder if business scalable enterprise managers know wtf "turnkey" means, you know, because it's totally awesome to have completely non-functional nor operational projects.
Now, turkey, on the other hand...
Name:
Anonymous2007-01-15 12:40
Worth mentioning only:
PHP - work - maintaining a portal of originally 200K lines of code (now 180K, removed crap, lots of changes, lots of code from me)
PHP - work - working on another portal of like 100K lines (writing stuff, maintaining others' code, lots of changes)
Python - home - working on a Python system shell and new-syntax parser, currently 1000 lines, will be 4K lines
Python - home - image viewer with my needs - classfy H, 16:9, etc - 500 lines
C - client that connects to an world server to render what it sees in a SNES RPG-ish style (3D objects, 2D rendering) - 9K lines
Java - yes, I suffered :( , stupid HTTP proxy with cache at uni - 1000 lines
DIV - Pang-like game with bosses, 2 players, demos, and various weapons, 4K+ lines
More stuff I'm missing
Name:
Anonymous2007-01-15 14:37
I wrote a functioning implementation of Tic-Tac-Toe for the Atari 2600.
Thread over
Name:
Anonymous2007-01-15 14:52
>>17
You can't stop threads just like that. I declare thread NOT over
Name:
Anonymous2007-01-15 15:27
C - client that connects to an world server to render what it sees in a SNES RPG-ish style (3D objects, 2D rendering) - 9K lines
Sounds interesting, explain more. And what do you mean (3D objects, 2D rendering), that's the whole purpose of the graphics pipeline, to convert a 3D representation of a scene into a 2D image that can be displayed on a monitor.
PHP: kickass captcha package (soon to be on sourceforge), nearly all the programming for http://www.vizions.com, apps to automate SEO processes, currently finishing up e-commerce modules for Drupal (some of which will be submitted to their community), java emulation classes for StringTokenizer to replace php's strtok functionality which is made of fail, php/ajax slideshow app, various crap dealing with SAPI for output filtering, and a bunch of other shit
C and C++: the usual academic stuff you end up doing
Name:
Anonymous2007-01-21 5:56
* Wrote TSR terminal emulator in assembler for DOS with internal ANSI decoding.
* Wrote a Unix telemarketing system. (C)
* Wrote a Unix shipping system with ISO-Maxicode support for Intermec 4100 label printers. (C / C++)
* Part of two man team that wrote an entire double-entry accounting system for Linux. (C++....A shitload of it)
* Presently writing a MapPoint-style plugin for QT and wxWidgets. (C++)
* Presently building and maintaining my own Linux distribution.
I know I got lucky and it won't last long, but so far I've done 3 major things. The first was like "that's what I was already doing at home". The second was like meh, this kinda sucks, but ok, you want this you'll have this, not much of a bother. The third was OMFG I always wanted to do this thank you sir! With a month worth of my own design.
Name:
Anonymous2007-01-21 19:00
I used to have fun at work.
After doing this crap for 22 years, it gets old. :)
Basically its an OO batch system. Get flexability with the objects, and speed of development with Perl's rich language features. Allows you to tie your job to file availability information from an automated file download system I also built. Massive amount of functionality built out - tie ins to all of the companies main database tables. All wrapped in shiny objects and manager classes.
Of course, now the buzzword happy managers are all circle-jerking to ruby, so the beautiful framework I have built will most likely be thrown out due to retarded people.
C# - 1/2 million lines, work
Ugh ... I despise Microsoft products. They work great until you decide to get a fragment of individuality and do something different. But yeah, built a good chunk of, and maintain most of, a 3 tier client/server application. Of course, the guys who built it are all retards, get paid way more than me, and none of them have to maintain the POS code they created.
Hoping to get permission to rebuilt it with Java, but again - the ruby-jerkers may force their retarded "Web 2.0 Ajax ZOMG SHINY" solution on us, whereby you can get something out there really fast, get your bonus, quit, and then leave me maintaining a bunch of uncommented garbage.
Java - 100,000 lines or so
Building a turn based strategy game engine using the shiny new Java templates in 1.5. Took them long enought to realize that they missed something from C++ ... finally good enums too. I enjoy this far more than work. Hopefully it will be successful when I release it to the world, and I can stop working for the Finance industry - IMO the most retarded industry in the entire world.
Name:
Anonymous2007-01-22 0:04
-_- It's not about how big the number of lines is it's about how small it is.
100 lines for a program is better than 500.
Name:
Anonymous2007-01-22 0:10
With that logic, I have just created the most powerful program ever... 1 byte.
Actually I would wager its neither. All depends on what you are going for. Especially with a language like Perl, where you can write pretty much everything as a one-liner. Instead, since I work in a team, I prefer to write it much more verbosely. Where I could AUTOLOAD setter/getter methods, I prefer instead to actually create those methods and document them in POD, so that way it doesn't leave the rest of the team confused. (Ruby guys still haven't figured this out)
There really aren't any good metrics for programming projects, although line count is a general indication of either complexity or developer stupidity.
Name:
Anonymous2007-01-22 3:37
>>32 (Ruby guys still haven't figured this out)
RubyDoc?
Anyway, Perl sucks, you shouldn't have to think about how to do something so that others can read it. That's why I use Haskell, it's mathematically logical, so anyone can understand anything as long as he understands the basic concepts behind it.
Now excuse me while I shove some arrows up my rectum.
Name:
Anonymous2007-01-22 5:45
>>29
Props for the Perl job, and no, managers don't fap to Ruby, wish they did. Unfortunately, they are still fapping to Java scalable enterprise solutions.
And you want to replace your C# stuff for Java? Crazy. Pray they want Python, Ruby, Perl, Lisp, anything good that is.
>>30
100 lines operating system, go! I agree that less lines _implementing the same functionality_ are better for many reasons (cheaper, easier, better to maintain and usually better to extend), and I'm always the lazy guy who thinks hard to work less, which my boss values as anything I'm asked to reimplement for some reason ends up being 1/4 of the original and somehow be more flexible (due to proper generalization), but sometimes shit just takes a lot of lines.
And that's as long as your lines are readable, i.e. i++;j++; is not better than i++; and j++;. Code beauty is important, you read mroe code than write.
>>32
Use Python, you don't even need getter/setter shit, just have properties, which may be simple properties, or get/set/delete functions defined in the class. This way you can do stuff like o.p += 2 without all the o.putShit(getShit() + 2) ugly stuff.
line count is a general indication of either complexity or developer stupidity.
Truth
Not documentation. The Ruby guys are still all excited about dynamic methods and classes. Most of the ruby hype is coming from the bloggers who can now make crap code on their own so much faster that they just need to tell everyone about it. Of course, when you start doing crap like that on a big team, it degenerates into massive confusion.
Ruby can still be done right, its just not what the hype is about right now.
Mine do, but not in the right way. They are more obsessed with being obsessed with Ruby. Got some old smalltalk guys reminiscing about how their language was so much better than everything out there, even though they never really bothered to learn what these new languages can do ... so now they fap to ruby since some other smalltalk guys told them to. Of course, they never bothered with Perl because they heard it was "hard to maintain" - even though they have never seen a line of Perl code or bothered to seek it out. Ignorance pisses me off.
Of course, when I say managers I mean IT managers. The middle guys who manage teams, not the higher ups. Although we do have a fairly good CTO right now, who is actually interested in Ruby.
Don't get me wrong, I like dynamic languages. But they fail hard when the projects get big, mostly due to the lack of good tools. You basically have to keep the whole object model in your head, since no IDE out there can figure out what is getting passed into a method in any of these kinds of languages. Its that way by definition, so I doubt its something they can ever get around reliably. You could probably hack at it, and try to find all possible method invocations, and all possible parameters, but thats uber-taxing on the CPU.
Thats why Java is a better choice for a large scale application. The code is more verbose, yes, but you gain lots of compile time checks, really good tools to help you with method completion and package importing. And its not Microsoft, so thats an insti-win.
I would love to write huge applications in Perl, but even with my zealotous streak, I can't advise it given the methods outlined above. Plus most dynamic languages have sucky UI libraries on windows. TK works alright, but there isn't a good grid control out there - nothing anywhere near whats available in Java or C#, that is.
And I hate bastardizing the web with "Web 2.0" abd AJAX, so thats out for me too.
Type-safety is not safety. Testing is safety. I've never understood the "dynamic language = unscalable" argument and I've worked on and with 5000-10000 line projects in Python.
Name:
Anonymous2007-01-25 19:06
I've worked on and with 5000-10000 line projects in Python.
lol wut?
If you think that's anything but very small, you're not qualified to have an opinion on the scalability of languages.
PS. Static typing and testing aren't mutually exclusive. xoxoxo
The scalability argument I was bringing up was not, in fact, about safety. It was about memory. Human minds can only keep so much on hand at any given moment. Context switching, and pulling from disk are expensive operations for we fleshy things. A typed language, and a good IDE to understand that language, take a lot of that responsibility away.
I don't have to remember that FooObject has barMethod, the IDE tells me. All I need to remember is the role of each object, and that ideological role is far easier to remember than every function name in every class in your entire project and all libraries, including builtins.
5000-10000 is nothing. As I mentioned before, I maintain a half million lines, which is a heck of a lot in a language as terse as Perl. Keeping the object model in my head requires a heck of a lot of mental RAM, something I don't have to do in Java.
And type-safety is a type of saftey. You can never call a method that doesn't exist (unless you really, really try) - and thats a nice little chunk of saftey right there. Knowing the type of arguments is also very nice for safety - for the whole not calling methods that dont exist thing. Especially when working with legacy code (which I do a lot of), this gets to be really important.
I do unit testing using Test::Harness, Test::More and Test::Class, which has let me hold this massive structure together. But even with that nice gamut of unit tests, you still run into fun errors that statically typed languages wouldn't get.
Name:
Anonymous2007-01-25 21:51
The scalability argument I was bringing up was not, in fact, about safety. It was about memory.
This is probably the most interesting insight I've read today.
I like static typing for catching errors at compile time, but this... is a really nice point.