I've already dabbled into Python and bought books, but I found its sytax too abstract (too much like pseudocode) and too strict.
Should I learn Ruby and Rails instead, considering that:
- I also want to learn Perl
- I'll use the language for webdev and general projects like games
- I have alredy some little experience with Python ?
I've also heard about Scala and the Lift framework, is it good?
>>1
Ruby is slow as fuck. And a TERRIBLY designed languages, no joke. Read some articles about its flaws and you'll realize how deep they are. Also, RubyOnFails is blaoted as fuck (creates hundreds of thousands of objects just for a "hello world" page...) and I haven't used Django but it's probably not much better.
Scala runs on JVM and is therefore shit in my eyes.
But really, Ruby sucks a fat one. If you thought Python sucked for syntax, Ruby sucks for that and every other of its design `features'.
If you wanna do very very simple games then why not C++ and something like SMFL (or preferably something with C). If you really wanna pick between Python and Ruby, stick with Python because it's at least slightly more sane than Ruby.
In your situation I would easily pick Scala.
Beware of Lift though, it's a bit... “different”.
Name:
Anonymous2012-02-20 8:20
Ruby, Python and Perl are all substitutable for one and other, having basically the same features, bone headed design having plagiarized each other shamelessly over the years, and are all SLOW AS FUCK, even if it doesn't seem that way due to the short start up time of their VMs. Learn just one and forget about the others.
Having said that, Python seems to have more demand than Ruby and is less fucking horrible than Perl.
On Scala I can't comment much. It seems to have been designed by educated people, but it haves roughly the same design goals as C++, only taking Java as a substrate. Due to this, I have stayed the fuck away from it. Still, it seems like decent choice, but remember that it's in a whole different category, by virtue of being statically typed (with type inference) and all in all attempting to meld Java and Haskell.
>>14 Having said that, Python seems to have more demand than Ruby and is less fucking horrible than Perl.
Yeah, but Perl has native regular expressions. This in turn can result is some very fast and efficient matching operations over a very large set of data.
>>20
This was a poor choice of complaints. You can roll your own TCO with static analysis and cleverness. But you can't get rid of those loading times...
Name:
Anonymous2012-02-20 17:38
Real games takes several seconds just to show up the first splash screen. JVM startup time is insignificant.
Name:
Anonymous2012-02-21 14:52
Ruby
- Ruby indulges obfuscation: Ruby has no keyword/optional arguments, so you'll have to use hash parameters as a substitute. This is an idiom that comes from Perl. Ugly, Perl-looking code, like proc {|obj, *args| obj.send(self, *args)} or (0..127).each { |n| p n.chr }, considered beautiful. Another confusing Perl borrowing are postfix `if` and `while` (line = file.readline while line != "needle" if valid line) and quirky variable names (partially due to naive environment design): @instance_var, @@class_var, CONSTANT_VAR, $global_var, :sym, &proc, $~[1], $!, $>, $@, $&, $+, $0, $~, $’, $`, $:, $., $* and $?. If A is [1,2,3] and B is [10,20,30], then A+B is [1,2,3,10,20,30], when you probably wanted [11,22,33]. If `a` and `b` are undefined, then "a = b" produces error, but "a = a" gives `nil`.
- Faulty syntax. Ruby cant distinguishing a method call from an operator: "a +b" can be both "a(+b)" and "a + b" - remove the space to the left of "+" or add a space to the right of "+", and it will be parsed as an addition. Same with "puts s *10", which is parsed as puts(s(*10)). Ruby's expressions terminate by a newline and you have to implicitly state that the expression is not over, using trailing + or \. That makes it easy to make a dumb syntactic mistake by forgeting to continue line. It also encourages putting everything onto a single line, producing messy looking code. A good amount of your code will consist of "begin end begin begin end end..." noise.
- Slow: JIT-compiling implementations exist, but they're still slow and incomplete, due to Ruby's complexity and bad design, which make Ruby difficult to optimize compared to other dynamic languages, like Lisp. For example, Ruby has to accomodate for somebody in another thread changing the definition of a class spontaneously, forcing compiler to be very conservative. Compiler hints, like `int X` from C/C++ or `declare (int X)` from Lisp, arent possible either.
- Ruby's GC is a naive mark-and-sweep implementation, which stores the mark bit directly inside objects, a GC cycle will thus result in all objects being written to, making their memory pages `dirty` and Ruby's speed proportional to the number of allocated objects. Ruby simply was not designed to support hundred thousand objects allocation per second. Unfortunately, that’s exactly what frameworks like Ruby on Rails do. The more objects you allocate, the more time you "lose" at code execution. For instance something as simple as 100.times{ ‘foo’ } allocates 100 string objects, because strings are mutable and therefore each version requires its own copy. A simple Ruby on Rails 'hello world' already uses around 332000 objects.
- OOP: Matz had a bit too much of the "OOP is the light and the way" philosophy in him, in effect Ruby doesn't have stand-alone functions and Ruby's blocks can't be used in exactly the same way as usual closures. Even high-order functions are attached to objects and produce verbose code: "names.map { |name| name.upcase }", instead of simple "map upcase names".
- Ruby (like most other scripting languages) does not require variables to be declared, as (let (x 123) ...) in Lisp or int x = 123 in C/C++. If you want a variable private to a block, you need to pick an unique variable name, holding the entire symbol table in your head. Ruby introduces new variables by just parsing their assignements, meaning "a = 1 if false; a" wont raise an error. All that means Ruby can't detect even a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo. Local and global scopes are unintuitive. Certain operations (like regular expression operator) create implicit local variables for even more confusion.
- "def method_missing(*args)" is a blackhole, it makes language semantic overly cryptic. Debugging code that uses method_missing is painful: at best you get a NoMethodError on an object that you didn't expect, and at worst you get SystemStackError.
- Non-othogonal: {|bar| bar.foo}, proc {|bar| bar.foo}, lambda {|bar| bar.foo}, def baz(bar) bar.foo end - all copy the same functionality, where Lisp gets along with only `lambda`. Some Ruby's features duplicate each other: print "Hello", puts "Hello", $stdout<<"Hello", printf "Hello", p "Hello", write "Hello" and putc "Hello" -- all output text to stdout; there is also sprintf, which duplicates functionality of printf and string splicing. begin/do/then/end, {} and `:` also play role in bloating syntax, however, in some cases, precedence issues cause do/end and {} to act differently ({} binds more tightly than a do/end). More bloat comes from || and `or`, which serve the same purpose.
- Ruby as a language supports continuations via callcc keyword. Ruby's callcc is incredibly slow, implemented via stack copying. JRuby and IronRuby don't have continuations at all, and it's quite unlikely they will ever get them. There were also support breaches in mainline Ruby, where Ruby 1.9 has not supported continuations for a while. If you want your code to be portable, I'd suggest not using Ruby.
- Ruby was created "because there was no good scripting language that could handle Japanese text". Today it's mostly Rails hype and no outstanding feature, that makes the language, like the brevity of APL or simplicity and macros of Lisp. "There is some truth in the claim that Ruby doesn’t really give us anything that wasn’t there long ago in Lisp and Smalltalk, but they weren’t bad languages." -- Matthew Huntbach
Name:
Anonymous2012-02-21 14:52
Python
I am far from an expert at Python, but I have done a couple of semi-serious projects in the language and will try to recall specifically what I didn't like.
- Everything you write will be open source. No FASLs, DLLs or EXEs. Developer may want to have control over the level of access to prevent exposure of internal implementation, as it may contain proprietary code or because strict interface/implementation decomposition is required. Python third-party library licensing is overly complex. Licenses like MIT allow you to create derived works as long as you maintain attrubution; GNU GPL, or other 'viral' licenses don't allow derived works without inheriting the same license. To inherit the benefits of an open source culture you also inherit the complexities of the licensing hell.
- Installation mentality, Python has inherited the idea that libraries should be installed, so it infact is designed to work inside unix package management, which basically contains a fair amount of baggage (library version issues) and reduced portability. Of course it must be possible to package libraries with your application, but its not conventional and can be hard to deploy as a desktop app due to cross platform issues, language version, etc. Open Source projects generally don't care about Windows, most open source developers use Linux because "Windows sucks".
- Probably the biggest practical problem with Python is that there's no well-defined API that doesn't change. This make life easier for Guido and tough on everybody else. That's the real cause of Python's "version hell".
- Global Interpreter Lock (GIL) is a significant barrier to concurrency. Due to signaling with a CPU-bound thread, it can cause a slowdown even on single processor. Reason for employing GIL in Python is to easy the integration of C/C++ libraries. Additionally, CPython interpreter code is not thread-safe, so the only way other threads can do useful work is if they are in some C/C++ routine, which must be thread-safe.
- Python (like most other scripting languages) does not require variables to be declared, as (let (x 123) ...) in Lisp or int x = 123 in C/C++. This means that Python can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data. Local and global scopes are unintuitive. Having variables leak after a for-loop can definitely be confusing. Worse, binding of loop indices can be very confusing; e.g. "for a in list: result.append(lambda: fcn(a))" probably won't do what you think it would. Why nonlocal/global/auto-local scope nonsense?
- Python has a faulty package system. Type time.sleep=4 instead of time.sleep(4) and you just destroyed the system-wide sleep function with a trivial typo. Now consider accidentally assigning some method to time.sleep, and you won't even get a runtime error - just very hard to trace behavior. And sleep is only one example, it's just as easy to override ANYTHING.
- Crippled support for functional programming. Python's lambda is limited to a single expression and doesn't allow conditionals. Python makes a distinction between expressions and statements, and does not automatically return the last expressions, thus crippling lambdas even more. Assignments are not expressions. Most useful high-order functions were deprecated in Python 3.0 and have to be imported from functools. No continuations or even tail call optimization: "I don't like reading code that was written by someone trying to use tail recursion." --Guido
- Python's syntax, based on SETL language and mathematical Set Theory, is non-uniform, hard to understand and parse, compared to simpler languages, like Lisp, Smalltalk, Nial and Factor. Instead of usual "fold" and "map" functions, Python uses "set comprehension" syntax, which has overhelmingly large collection of underlying linguistic and notational conventions, each with it's own variable binding semantics. This, in effect, makes Python look like an overengineered toy for math geeks. Good luck discerning [f(z) for y in x for z in gen(y) if pred(z)] from [f(z) if pred(z) for z in gen(y) for y in x]. In addition, you will enjoy cryptic expressions like z(*z(*m.i())[::-1]).
- Forced Indentation of Code (aka "off-side" rule) impedes using CLI, automatically generating Python code and moving around large code blocks. Editing Python code requires special editors (forget about Word/Notepad), that expand tabs into spaces, while sharing code through a web post or email will most likely break indentation. Absence of block-terminator is so utterly confusing, that you'll find yourself ending blocks with #endif anyway. It's painful to deal with other things that need indenting, such as large SQL queries, or HTML when you're using things like mod_python.
- Python hides logical connectives in a pile of other symbols: try seeing "and" in "if y > 0 or new_width > width and new_height > height or x < 0".
- Python indulges messy horizontal code (> 80 chars per line), where in Lisp one would use "let" to break computaion into manageable pieces. Get used to stuff like self.convertId([(name, uidutil.getId(obj)) for name, obj in container.items() if IContainer.isInstance(obj)])
- Quite quirky: triple-quoted strings seem like a syntax-decision from a David Lynch movie, and double-underscores, like __init__, seem appropriate in C, but not in a language that provides list comprehensions. There are better ways to mark certain features as internal or special than just calling it __feature__. self everywhere can make you feel like OO was bolted on, even though it wasn't.
- Python has too many confusing non-orthogonal features: references can't be used as hash keys; expressions in default arguments are calculated when the function is defined, not when it’s called. Why have both dictionaries and objects? Why have both types and duck-typing? Why is there ":" in the syntax if it almost always has a newline after it? The Python language reference devotes a whole sub-chapter to "Emulating container types", "Emulating callable Objects", "Emulating numeric types", "Emulating sequences" etc. -- only because arrays, sequences etc. are "special" in Python. Subtle data types (list and tuple, bytes and bytearray) will make you wonder "Do I need the mutable type here?", while Clojure and Haskell manage to do with only immutable data.
- Python's GC uses naive reference counting, which is slow and doesn't handle circular references, meaning you have to expect subtle memory leaks and can't easily use arbitrary graphs as your data. In effect Python complicates even simple tasks, like keeping directory tree with symlinks.
- Patterns and anti-patterns are signs of deficiencies inherent in the language. In Python, concatenating strings in a loop is considered an anti-pattern merely because the popular implementation is incapable of producing good code in such a case. The intractability or impossibility of static analysis in Python makes such optimizations difficult or impossible.
- Problems with arithmetic: no Numerical Tower (nor even rational/complex numbers), meaning 1/2 would produce 0, instead of 0.5, leading to subtle and dangerous errors.
- Poor UTF support and unicode string handling is somewhat awkward.
- No outstanding feature, that makes the language, like the brevity of APL or macros of Lisp. Python doesn’t really give us anything that wasn’t there long ago in Lisp and Smalltalk.
>>26
care to explain brain-damaged scumbag? all your objections to Python doesn't hold on JVM (GIL, lol), now gtfo and learn Scala (or Jython)
Name:
Anonymous2012-02-21 15:18
>>28
Static typing introduces a lot of complexity: inference, type classes, algebraic data types, existential types, phantom types, etc. That's a lot of buzzwords to even start writing code, and static typing has nothing to do with functional paradigm. While dynamic typing doesn't catch type mismatch problems before accepting to compile your program, it's very simple to use and has a very low mental requirement - ideal for doing something other than type systems research. The error messages given at run-time on type errors are much simpler than cryptic compile-time error messages.
Statically typed languages have a very painful syntax, it's a far more complex one than Lisp's. You need to be wary of operator precedence, layout rules and other syntactic sugars, which can be a stumbling block when using the language. Scheme has the simplest syntax of any other practical programming language. The rules can be explained in minutes. The syntax is unlike what most people are used to, especially if they come from a C-syntax background, but it’s easy to pick up and use.
Inspired by mathematics, some statically typed languages use lazy evaluation, meaning it is harder to understand when something will happen or write efficient software. Lisp has intuitive eager evaluation, which is what most human beings are used to.
The "REPL" of statically typed languages does not expose the entire language, it is very limited: you can't modify every aspect of your program as you would in Lisp, so it impedes testing things interactively in GHCi. Statically typed languages also can't efficiently load code at run-time, meaning you can't use statically typed languages for CLI or scripting as you can use Lisp in interpreter mode.
There are no easily accessible, SICP-like, books for statically typed languages. Some of the newbie-oriented books (like TAPL) are actually quite daunting, making it hard to suggest reading material to somebody who has no background in mathematics.
>>29
Personally I consider static typing to be a premature optimization. The only appropriate way to use types is to make them optional. Mandatory static typing is crippling to human thought.
Statically typed languages have a very painful syntax...
Nope, look at Scala. With type inference it's nice and clean and I don't mind learning language rules (and most operators are actually functions).
Inspired by mathematics, some statically typed languages use lazy evaluation
In Scala you can choose.
>Statically typed languages also can't efficiently load code at run-time
Bullshit. You just need some interface. And byte-code modifications at runtime is used in almost everywhere, so you can do anything you want (AspectJ).
There are no easily accessible, SICP-like, books for statically typed languages.
Bullshit. You just made that up.
The error messages given at run-time on type errors are much simpler than cryptic compile-time error messages.
Bullshit. At runtime you get "cannot cast X to Y" which is same shit as compile time error. What's worse, you get it at runtime.
>>30
Another good thing with static typing is that IDE can highlight type errors in real-time, show you type hierarchy, ... And I don't give a fuck what's your opinion on IDEs.
There are no easily accessible, SICP-like, books for statically typed languages.
Bullshit. You just made that up.
Oops. Sorry. I didn't realized you talk about theory. You may be right. I don't know. I'm just corporate monkey coder.
Name:
Anonymous2012-02-21 16:17
1. Static typing reminds me of the dark ages of programming in the c family of languages. Inference engine saves me from writing the boring type declarations but it's far from perfect. I have nothing against static typing if it's optional. One of the coolest features of lisp that I found when I started learning it coming from c++ was that I could put anything into lisp containers. And I don't want going back.
2. No rapid development. Don't get me wrong, developing in Haskell is faster than in c++ or c# but compared with ultimate RAD vehicles like lisp or prolog, haskell looks like a family caravan against full blood racers. Haskell doesn't allows me to experiment. It doesn't allows me to create modulus with some functions undefined or defined wrong. Bundle this together with loading file to redefine a module, the cruppiest feature they took from Prolog and you'll start to value your lisp listeners.
3. Hogs a lot of brain resources. It's syntax is complex, and together with static typing it forces me to spend more resources on dealing with language than with dealing with the problem.
4. Inflexible- Remember the Alan Kay quote - Lisp isn't a language it's a building material. Not so with Haskell. You can not wrap the Haskell around the problem as you can do with Lisp. Haskell forces you to work the other way around.
5. Spartan development enviroment. Compared with lisp offerings WinHugs looks poor man's IDE. There are so much things that are missing that I don't know where to start. Beside I had to write Haskell code in notepad, best editor available under windows, after Crimson failing to start after I switched to Haskell mode. And don't even dare to mention Emacs, a lot of people don't like it.It's 2008 and creating a simple Haskell editor is not an rocket science. I need an integrated editor with syntax coloring and intellisense kind of reminding me how many and what type of arguments function takes. That's it. Another option is Visual Haskell, used as editor together with winhugs, for interactivity. Also there is no debugger, so forgeth about stepping, functional style of Haskell, helps here but it's just a hassle debugging by hand.
6. Lacks reflexive abilities. Oh silly me of course it lack them. In Haskell everything is carved in stone. Programming in Haskell is like proving a mathematical theorem. There is no screwing around. It's like life in a monastery, full of fasting, praying and compassion under the all seeing eye of the abbot, punishing you for every mistake. So if this kind of life is for you, you'll end up in heaven, but if you want playing around and can't (don't) want life without women, parties, drinking and good food than Haskell is definately wrong choice.
7. Case sensitive - why does types has to start with uppercase and functions with lowercase. To make it easier for the implementation writers? Or to enhance readibilty. The latter has other way to be achieved. Any syntax coloring editor is smart enough to gave you visual clues what the hell some name means.
>>34 Haskell doesn't allows me to experiment. It doesn't allows me to create modulus with some functions undefined or defined wrong.
main :: IO ()
main = undefined
[1 of 1] Compiling Main ( undefined.hs, undefined.o )
Linking undefined ...
See, I know you're a troll. I know it, dog. The only question in my mind is why you wrote such a long post about it with such obvious factual errors. I can't tell if this makes your technique sloppy or subtly ironic.