Ugly jobs

Obviously jobs like "game programmer" are very crowded and the possibility of getting in are almost null.

What are some jobs that look "ugly"? I guess that it's easier to get a non appealing job.

dog catcher

Garbage collector man

>>1
So let me get this straight: instead of developing valuable skills or even trying to come up with the right lies to put on your resume, your plan is just to apply for jobs no one else would touch?

>>4
Yeah, ones like Lisp developer, Haskell developer, Prolog developer

Anything involving legacy systems e.g. COBOL or an obfuscated language like Perl.

MUMPS jobs

I would touch them.

THE CYBERJEWS WERE HERE

jobs like "game programmer" are very crowded
All `-programmer` jobs are crowded.

What are some jobs that look "ugly"?
Army service? Cleaning toilets in fast-food restaurants? Yeah. You can.

If I were you I'd learn the fuck out of some database shit and become a database admin... easiest fucking job in the world. Right now where I live there's huge demand for sharepoint developers... which is also a joke. But my first choice would be a database developer.

>>11
All IT people despise those primadonna fuckwits known as DBAs. Seriously talk about a bunch of people that think they know everything when in fact they don't know jack shit.
Not being negative; just keeping it real.

What are some jobs that look "ugly"?
Garbage collector person in Ocaml.

>>#
I chuckled.

someone stated that they have jobs, in another thread.
they were lying.

>>15
i have a job

Work at Microsoft or Apple.

>>17
Whats wrong with Apple? Jobs at least loves dynamic languages and allows Objective-C.

>>18
Objective-C
IHBT

>>19
There was even extension to Obj-C to allow closures (code block), so you can write most of your code in Lisp, then translate in Obj-C.

>>20
http://users.telenet.be/stes/block98.html

>>18
Please kill yourself.
All Apple fanboys need to die.

>>22
Enjoy your C++ BDSM

>>20
so you can write most of your code in Lisp, then translate in Obj-C.
OH MY GOD I HAVE BEEN TROLLED SO MUCH TODAY OH GOD THAT'S THE KING OF TROLLS 11/10 I RAGED SO MUCH I HATE YOU I HOPE YOU DIE

>>24
I'm serious.

>>25
Have you ever used Lisp? It's not all lambdas and closures, it's all eval/apply, macros and code=data.
First Lisps had dynamic scoping, so they couldn't even have proper closures.

>>26
>it's all eval/apply, macros and code=data.
I know, but the idea is to use Lisp as a macroprocessor. Of course eval wouldnt be possible, as Obj-C is still a static language.

>>27
Using Lisp as preprocessor/macroprocessor defeats the purpose to have Lisp-style macros, as you break the code=data, you'd need to produce "strings" in the macros, instead of (lists). They would be more powerful than C macros, but limited compared to Lisp-macros-for-Lisp.

Of course eval wouldnt be possible, as Obj-C is still a static language.
Then how would you emulate it, when translating Lisp code to ObjC?

>>28
Then how would you emulate it, when translating Lisp code to ObjC?
The only way is to include complete Lisp-interpreter itself.

>>28
>you'd need to produce "strings" in the macros, instead of (lists).
You need to produce "strings" only for special forms, like "if" and "funcall"

>>29
It's inefficient and faggish, why would you include the FULL Lisp interpreter for a compile-time macro processor?

That's how Lisp compilers produce standalone executables, and everyone bitches about it because OMG IT'S HUEG.

>>31
>OMG IT'S HUEG.
Modern programs frequently support scripting capabilities, so they include complete interpreters. And Lisp-interpreter is simplier and smaller than, for example, Python interpreter. Comparing to the size of expanded C++-templates, humble 100 kb of interpreter isnt a big deal.

>>32
so they include complete interpreters.
WRONG.

Almost all the interpreters out there provide an API or a similiar interface to the interpreter to access it from a program. You need to install the interpreter to use the software's scripting capabilities.

A Lisp interpreter includes the huge ANSI Common LISP library plus some implementor-specific extensions. The size of SBCL's tarball is 9.1MB, the compiler is around ~3MB.
Racket's interpreter/JIT compiler is 2.4MB, without counting the libraries.
Add to that the size of your application. That's not 100kb.

>>33
compiler != interpreter

>>34
A Lisp compiler*

>>33
It depends. SBCL is probably one of the largest CL implementations when it comes to code size. ~8-10MB is more common for other natively compiled ones, but if you remove the compiler and other unneeded libraries, you get much smaller sizes. ECL (compiles to C->native + bytecode compiler/interpreter for when the C compiler isn't available) takes 500KB, but if you include other components the size may increase by some 1-4MB. ClozureCL is about 15MB. I'm not entirely sure about Lisp Works' runtime, but it's under 20MB. Allegro CL is ~13MB, but size differs depending on what you include and if you use a tree-shaker. Of course, if you were to use compression, it'd be much smaller. A more limited CL (Win32 only) called CormanLisp compresses its image with zlib, leading to a total 2MB size for the entire thing. Compressing a SBCL 32bit core makes the size go down from 25MB to 5MB.
If you only want a limited lisp interpreter, it could very well be tiny, see http://code.google.com/p/lisp5000/source/browse/trunk/lisp500.c or many toy Scheme implementations (non-toy ones tend to be larger).

>>36
There are ECL (as you said), Guile, TinyScheme and others that exist specifically to being embedded in C programs, but you still need the runtime libraries.

But it doesn't resolve the compile-time lisp code execution nor the ObjC integration one.

I don't know much about ObjC integration, although I think some implementations (was it ClozureCL?) have Objective-C briges, however I've never looked into the details, so I can't say for sure. As for compile-time code, it should be fine as long as you don't need COMPILE or EVAL. Macros are expanded at compile-time, and as long as you don't need to compile at run-time, you don't need to include a full-fledged compiler.

>>37
ObjC has metaclasses and reflection, so interfacing with it is much easier than with C++.

>>26
Are you retarded? In any normal Lisp program, calling EVAL means you done fucked up somewhere, and macros wouldn't prevent compiling to Objective-C, seeing as how they're a compile-time construct.

>>40
REPL calls eval every time.

>>41
But you're not writing a listener, stupid.