Help with login code on Python!!!!!
#26
Posted 30 April 2012 - 08:43 PM
#27
Posted 30 April 2012 - 09:35 PM
class Browser attr_accessor :name, :version, :responded def initialize(name, version) @name, @version = name, version end def visit(url) # HTTP stuff @responded = true end end my_browser = Browser.new 'Firefox', 11 my_browser.name # => 'Firefox' # upgrade my_browser.version = 12 my_browser.visit 'neocodex.us' do_something if my_browser.responded
Being able to code like this is significantly more intuitive than having to do things like my_browser.get_name() or my_browser.set_version(12). They're objects, they behave and look just like objects, even though everything is secretly just method calls.
foo is a terribly contrived example that doesn't prove your point very well. As I mentioned, the members of the Ruby community aren't out to fuck each other over; variables tend to be named well enough that context alone informs the reader of their intended usage.
The catch-up you talk about is not really language features but tools that were built with the language. It would be unfair to compare those as language features. They don't really have a place in this discussion, sorry to say .
So a language is... just its syntax? I don't quite follow. Programming is an ecosystem and languages constantly evolve new tools to allow developers to code more effectively in them; how this is not to be taken into account when considering a language is beyond me.
a = a nilIf a language's consistency should be ascertained from how it handles silly edge cases that will never appear in production code, you've got me. Otherwise, stick to reality if your critique is to be taken seriously.
ArgumentError: invalid value for Float(): "03.a22"See above.
Your criticism of how a bare rescue worked in 1.8 genuinely made me laugh. I don't know if you were merely grasping at straws, or if your shop is legitimately that uninformed, but rescuing an exception without specifying exactly which one(s) you're preparing for is a far more real-world example of potential bug introduction. Timeout's most common use case is preventing the program from hanging should a network call not return in a reasonable amount of time; rescuing agnostically is very bad for this. Surely you want to be able to react differently to a SocketError, no?
The point can hardly be argued against, but Ruby's complexity is directly inline with its stated goal: to make programmers happy. The most obvious way to do this is to allow them to code in the way that best fits the way they think, and that involves exposing options; options naturally beget complexity, but I don't agree that the word need always connote a negative.I think it's pretty clear from these visualizations that Ruby has a much more complicated syntax.
It will always be so that no language can possibly be "the right one" for every programmer, but Ruby's pliability makes it a far better candidate than many of the alternatives. I also think it's this notion of "do whatever you want, within reason" that has put it at the forefront of innovation. Python and Ruby are both Turing-complete, general-purpose languages, and can as such be used to the exact same ends, but the sense of openness seems to convince Rubyists that trying something new will work and thus inspires far more creativity. Sinatra is, I think, the perfect example of this:
get '/profile/:user' do 'Hello, %s.' % params[:user] end @app.route('/profile/<user:user>') def hello(user): return 'Hello, %s.' % userThe DSL that Sinatra exposes really does feel like you're programming in a different language; Ruby's grammar is complex, absolutely, but out of it springs the ability to create remarkably intuitive new paradigms that better fit the problem at hand, and thus make developing solutions to said problems much more enjoyable. This contrasts markedly with the Pythonic approach, where TOOWTDI means Flask has to attach a decorator function to every route and a separate function has to be declared to handle it; the language gets in your way when you try to do something new by forcing you to conform to old standards. The virtue of this approach is lost on me.
As you've said, to each their merry own.
Edited by Inkheart, 30 April 2012 - 09:39 PM.
#28
Posted 30 April 2012 - 11:10 PM
I'm in favor of Ruby over the Ruby vs. Python argument. But I've barely used python so I can't speak well for both.
Hydro made some good points. The versatility in the language's grammar is meant to make it easier for programmers to adapt but at the same time all those different styles make for difficulties when reading other people's code. For that reason companies should conform to some guidelines for their code base to make it easier to maintain. The place I used to work at did exactly this. Before you were allowed to start pushing your changes you had to be briefed on how the code was to be written and formatted and such...
I'm curious though Hydrogen, what's your favorite scripting language?
#29
Posted 01 May 2012 - 03:15 AM
Hey, so, what made you choose Python? : P
I'm doing it at school currently and I picked it up pretty fast, so I thought I'd get more advanced with it
Dayum you guys are smart!
PS. Still having problems with the neopets login :'(
#30
Posted 01 May 2012 - 06:01 AM
I'm doing it at school currently and I picked it up pretty fast, so I thought I'd get more advanced with it
Dayum you guys are smart!
PS. Still having problems with the neopets login :'(
Yeah, that makes perfect sense. No sense in trying to juggle two different languages if you're forced to use one somewhere. Stick with it. urllib2 is pretty nasty and can be difficult to initially wrap your head around. I would very strongly recommend giving requests a try.
#31
Posted 01 May 2012 - 01:16 PM
I'm doing it at school currently and I picked it up pretty fast, so I thought I'd get more advanced with it
Dayum you guys are smart!
PS. Still having problems with the neopets login :'(
Take a look at my daily doer's code. Are you using mechanize?
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users