Whether I'm a programmer

if I use Lisp and call other languages "inferior" or do I need to accept Java and Python to be a truly faithful programmer?

Whom should I consult on this question of religion?

>>1
An idiot will use only one language. You may consider anything other than Lisp to be inferior, but Lisp won't be the right tool for the job every time.

And if anyone replies with LOL U CAN JUST MAKE A DSL PROBLEM SOLVED, then you've proven my point, faggots.

So to repeat what has been mentioned before, learn your Lisp (SBCL), pick up a scripting language (preferably Perl or Ruby, even though to many, Ruby is SLOW AS FUCK, but it has its uses), and learn a compiled language (C).

Consult my anus.

1. Type-aware IDEs (Eclipse plugins, IntelliJ, etc.) are hard and become barriers to entry. The compilation environment is no longer static–the IDE still transforms X to Y, but while transforming X to Y, it also has to put errors on the right line, squiggles under the right words, pop ups at the right place, cache the entire program’s type data to provide instant navigation, and all while the user is flying around the source file changing things and trying to make the IDE developer’s life a nightmare. Type-aware IDEs also stifle innovation as they become a barrier to entry for new languages. Designers of new languages can’t just have a great language, with a great library, with a great community–they also need to invest a very non-trivial amount of time into an Eclipse plugin.
2. Type systems are hard. Type theory is a very academic field. You don’t see hobbyists sitting down and writing a new type system for their language over the weekend. But you see plenty of hobbyists sitting down and writing a new syntax for their language over the weekend.
3. Consequently, static languages always lag behind dynamic languages. Especially with regards to syntax. I wish static languages evolved at the rate that dynamic ones do, as I like shiny new things as much as the next programmer.
4. Type systems can be too constraining. I’ll accept that they occasionally need to be circumvented for the better good. (However, I don’t think needing to circumvent the type system maybe 5% (if that) of the time in your application means that the other, more normal, bland 95% of your program needs to also give up type checking.)
5. Compile-time meta programming is still a fringe technique. Much to my chagrin, compile-time meta programming is not going to be in a mainstream static language anytime soon. Despite promising alternatives (boo, nemerle, lombok, groovy++), it’s lacking from more leading “Java next” contenders like Scala.


1. Dynamic languages are well-known for their “reload on the fly” productivity. Code can be changed without restarting a process, leading to a faster feedback loop for developers.
2. Dynamic languages often have better designed libraries. Java in particular is known for it’s ugly APIs. Very often, the problem is just that an API lacks higher levels of abstraction. Perhaps there is a larger reason why dynamic languages have nice APIs.
3. I’ve read very good, good, bad, and very (very) bad code in both dynamic and static languages. Admittedly, the type checks, IDE tooling, etc. is quibbling, because a good programmer should be able to produce good code in either type of language.

>>2
But why Lisp isn't "the right tool" for any job? I clearly see that Lisp is a silver bullet and can be used to easily solve any problem.

>>5
You mean just like every other programmer who has the most experience with language X?

>>6
What useful other languages have, except static typing and BDSM-shits, we, lispers, can easily replace with macros?

>>7
C/C++ has:
* No compile time encapsulation
* Outstandingly complicated grammar
* No way to locate definitions
* No run time encapsulation
* No binary implementation rules
* No reflection
* Very complicated type system
* Very complicated type-based binding rules
* Defective operator overloading
* Defective exceptions
* Duplicate facilities
* No high-level built-in types
* Manual memory management
* Defective metaprogramming facilities
* Unhelpful standard library
* Defective inlining
* Implicitly called & generated functions

>>6
You mean just like every other programmer who has the most experience with language X?
I hate your language X very much, not because it lacks feature Y, but because code that I write in X has a nasty habit of just not working, without any indication of why it isn't working. Lisp never gives me that trouble, and even when my Lisp code doesn't work, the tools available for debugging it (namely profilers, stack traces and functional style free of side effects) are so vastly superior to anything that I have found for X that fixing my problem is simple. And, seriously people, a language's speed is becoming less relevant with each new increase in processor speed, I would much rather program in a fast enough language that works and makes sense than in an unintuitive, convoluted piece of shit like X. --Lisper

>>9
Too bad over half of your libraries are FUCKING OUTDATED

>>10
Lisp community has no Big Brother support, like Google, Microsoft or Oracle.

>>2
and learn a compiled language (C).
Any language can be compiled, Lisp has compiler.
Did you mean low-level language? Forth.
Did you mean a language for system programming? FFI.

>>7
except static typing [...] can easily replace with macros?
Racketeers proved you wrong. We've got a pretty nice type system.
CL has type annotations.

>>9
You clearly don't understand Lisp, it's not about features, programming languages should be designed not by piling feature on top of feature, but by removing the weaknesses and restrictions that make additional features appear necessary.
At the core, Lisp does this, and does it good. C++, C, Java, C#, ..., get a new feature every month or so, so they're not really designed with that in mind.

>>12
nice
type system
stop trolling.

>>13
That's not the point, stop being a moron.

>>14
Whats wrong with "being a moron"? I'm still smarter than people who use "static typing" in their apologetics: it's like saying "our city has a lot of niggers", because static-typing people are niggers of Lisp community.

``Strong typing is for weak minds.'' - Dirk Riehle

>>16
Lisp is weak typed, because most of your data are lists.

>>17
You're confusing Lisp with Scheme.

>>18
There's a similar opposition between the use of lists to represent things and the use of "objects" with named, typed fields. I went through a stage, after I'd been programming in Lisp for 2 or 3 years, where I thought the old way of using lists to represent everything was just a hack. If you needed to represent points, surely it was better to declare a proper structure with x and y fields than to use a list of two numbers. Lists could contain anything. They might even have varying numbers of elements.

I was wrong. Those are the advantages of using lists to represent points.

Over the years my appreciation for lists has increased. In exploratory programming, the fact that it's unclear what a list represents is an advantage, because you yourself are unclear about what type of program you're trying to write. The most important thing is not to constrain the evolution of your ideas. So the less you commit yourself in writing to what your data structures represent, the better.

>>17
That's not weak typing.

>>16
duck typing is for ducks

What do you use when strong typing is not enough?

>>22
Dick typing

>>22
Touch typing

Ducks are Touring-complete, so types in Duck Typing are Touring-complete.

After my scanner stopped working (I guess 2000 pages was too much for it?), I kind of just lost motivation.

I have to work with Jewish Calendar in Python. I want to know if there is a Jewish Calendar in Python or if there is import in python