Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-4041-

python

Name: Anonymous 2010-09-24 14:55

hi. I'm not a programmer or anything. I just know some PHP and the obligatory web developer bullshit. is Python a good language for a non programmer like me to start with? what's your expert opinion on this lang.?
thank you!

Name: Anonymous 2010-09-24 15:06

Learn a real language, kid.

Name: Anonymous 2010-09-24 15:14

like I said, I don't have much knowledge on the subject. what do you consider a real language?

Name: Anonymous 2010-09-24 15:20

Ask yourself... "how easy is to build balls of manure with python?"

Name: Anonymous 2010-09-24 15:25

Python is perfectly fine to learn with.

Name: Anonymous 2010-09-24 15:32

>>5
That's way too ungay.
I vote for either Scala, Clean or Haskell.

Name: Anonymous 2010-09-24 15:34

>>6
Those languages are for academic faggots.

Name: Anonymous 2010-09-24 15:36

>>4
wat

please, tell me what you consider "real languages"

Name: Anonymous 2010-09-24 15:37

's good.

But you will hate the Tab/Spaces issue. Is a pain in the ass... But you can get accustomed to that.

I prefer Ruby and Perl though.

Name: Anonymous 2010-09-24 15:44

>>9
why do you prefer those?

Name: Anonymous 2010-09-24 18:25

>>1
No programming language is a good language for a non-programmer. If you wish to become a programmer, however, Python is a good choice for you.

>>10
Perl is a very messy, quick hack type of language with a syntax designed by a 12 year old on drugs. Ruby is mid way between Python and Perl. Less Pythonic, but more messy. Python has better libraries for doing all sorts of things and better support everywhere.

Name: Anonymous 2010-09-24 20:07

Perl is a very messy, quick hack type of language with a syntax designed by a 12 year old on drugs. Ruby is mid way between Python and Perl. Less Pythonic, but more messy. Python has better libraries for doing all sorts of things and better support everywhere

Seriously, you're so full of bullshit it actually becomes funny

Name: Anonymous 2010-09-24 20:37

Python is good to learn. Go for it!

Name: Anonymous 2010-09-24 20:59

>>12
I left that one alone. One thing... is the bit about the libraries false on its face? I don't like Python libs because they like to throw exceptions at the drop of a hat but that's just me. More broadly though, I just can't imagine Python beating Perl on libraries in any sense at all.

Name: Anonymous 2010-09-24 21:10

>>14
If you don't like exceptions, go to a language that doesn't support them (like C, where you use return codes) or a language with a strong enough type system to make exceptions uncommon (like ML or Haskell).

Name: Anonymous 2010-09-24 21:39

Python's alright to learn the basics.
Eventually you'll want to move up and learn something like C++, Haskell, or perhaps even LISP.

Name: Anonymous 2010-09-24 21:41

>>15
Again with the all-or-nothing. I just don't think its right to be so eager about throwing exceptions. Can't allocate memory? That's exceptional. File existence test negative? That is, in my opinion, not.

As for type systems, I would be sweeter on Python if it had stronger typing now that you bring it up.

Name: Anonymous 2010-09-25 5:00

>>16
C++?

>>17
Python's is fairly strong, just very dynamic.

Name: Anonymous 2010-09-25 6:50

>>18
Sure, but it's nowhere near strong enough. Without more richness it's like having a stockpile of rocket fuel and bic lighters.

I find static systems are almost always superior because few dynamic systems have anything that trumps knowing something at compile time about the state of affairs at runtime.

Name: Anonymous 2010-09-25 9:54

>>19
Static typing is worthless, quit kidding yourself.

Name: Anonymous 2010-09-25 10:41

[quote]>>19
I find static systems are almost always superior because few dynamic systems have anything that trumps knowing something at compile time about the state of affairs at runtime.
[/quote]

Nothing you can't overcome by implementing proper testing techniques.

Besides, you will get boners when all your tests passes. I fucking love TDD

Name: Anonymous 2010-09-25 18:49

>>21
Tests are one thing, but if you're testing for type correctness directly you've got problems, and tricky in most type systems that would call for it.

I'm not saying dynamic type systems don't have their place, I use them quite a bit in fact. Most of the time they're a product of something else: using a completely static type system in certain languages would conflict with the strengths of the language. But as for the type system itself there's rarely anything fantastic going on, except some clever mechanics for coping with the specific challenges presented by type semantics in that language.

Name: Anonymous 2010-09-25 20:29

>>22
It's pretty simple: if it works, the types are correct.

Name: Anonymous 2010-09-25 20:50

>>23
Even Dijkstra had more sense than that.

Name: Anonymous 2010-09-26 4:30

Dynamic typing means you waste less time defining stuff, and stuff you did for some purposes just magically works for some other purposes you may want to give it later on, without having to inherit or implement whatever object-oriented bullshit. For example:

def dup(x):
    return x + x


You may have thought out that for numbers, yet it also works for strings and lists, and if you later implement another collection type supporting __add__, it'll also work there. Time wasted defining types: 0.

Name: Anonymous 2010-09-26 4:40

>>25
Okay genius, you've cleverly called it dup, yet it returns 2*x for numbers. As numbers appear to be the primary target for this method, wouldn't you expect consistent effects for other types? Oh wait, no, it'll concatenate a string onto itself. And lists? I'd have wanted a listy version of the numbers one, where it doubles each member, but no, you just get a list that's twice as long.
Dynamic typing is inconsistent garbage. Also:
__add__
SLOW AS FUCK

Name: Anonymous 2010-09-26 6:03

>>26
class (Additive a) => Duppable a where
  dup :: a -> a

instance Duppable Int where
  dup x = 2 * x

instance Duppable [a] where
  dup a = a ++ a


Please enjoy consistent garbage then!

Name: Anonymous 2010-09-26 10:01

>>27
That's no moon. Oh. I mean Python.

Name: Anonymous 2010-09-26 15:55

>>26
Did you just confuse dynamic typing with poor operator definition choices? Come back when you know what dynamic typing is.

Name: Anonymous 2010-09-26 16:00

What's dynamic typing?

Name: Anonymous 2010-09-26 16:49

>>30
In Python's implementation, it means a series of features and things which happen:

1. Values have types, but variables (and object/dictionary/list/set slots) don't. Any variable may carry any type of value and be reset to a value of a different type.

2. Objects are implemented with dictionaries, and may hold any attributes. Objects may be modified, and classes are objects so they can be modified as well (except classes written in C/C++, which unfortunately cannot be edited, though their instances can). You can add or remove attributes (which may be callable attributes, i.e. methods) and you can even change an object's type anytime if you so desire, or change the class attributes (and methods) classes provide to their objects.

3. Everything is an object, and every operation is an object method call, including infix operators which are expanded to method calls (e.g. 3 + 5 is expended to (3).__add__(5)). Python performs no type checking whatsoever, and just attempts to call methods on objects as required. You can do o.f(x, y) to any object o, which will work as long as o has an attribute f which is applicable and supports at least two parameters (actually three, since in Python methods the first parameter is self/this). So if o has an f which supports (x, y) then f is executed, and whatever f does with x and y, Python doesn't care, but if f does x + y, x better be an object which supports __add__ and its __add__ implementation better support whatever y is.

So in essence, you can do anything as long as it works, and you don't ever have to define or require types unless you want to explicitly test for something and throw TypeError if you don't like what your function got. And again, you should not do something like:

def dup(x):
    if type(x) == int:
        return x + x
    else:
        raise TypeError('I wanted an int wah wah wah ;____; (protip: write your own dup for your x, loser)')


but you should rather do:


def dup(x):
    try:
        return x + x
    except:
        raise TypeError("Your stupid object doesn't support what I wanted to do, give me something —whatever— that knows how to + itself")

Name: Anonymous 2010-09-26 17:09

>>31
You went off the rails after #1. Dynamic typing has nothing to do with the other stuff, even in Python.

Name: Anonymous 2010-09-26 18:40

>>32
http://en.wikipedia.org/wiki/Duck_typing

They call it duck typing in the Python community.

Name: Anonymous 2010-09-26 18:41

>>33
Your point?

Name: Anonymous 2010-09-26 18:42

>>29
Come back when YHNBT. Dynamic typing is nice for interpreted languages, but >>25's example was stupid.

Name: Anonymous 2010-09-26 19:06

>>35
What does dynamic typing have to do with interpreted languages?

Name: Anonymous 2010-09-26 20:25

>>35
Yeah, because you can't compile a dynamically typed language oh wait

Name: Anonymous 2010-09-26 23:20

>>25
That is the dumbest argument for duck typing I have ever seen in my life.

Not to mention the fact that you can do it in statically typed languages too.  Like Haskell.


dup x = x + x


Incidentally, even though the Haskell version requires less typing, it will also check at compile time to ensure that you don't pass it a type that doesn't have an implementation for +.

Name: Anonymous 2010-09-27 0:01

>>38
Type inference has fuck-all to do with dynamic typing.

Name: Anonymous 2010-09-27 0:40

>>25,38,39
Read the post (38) again, notice it says "Not to mention that you can do it in statically typed languages too."  My point was that the example provided in 25 was dumb because it had nothing to do with dynamic typing.  Here's a C++ version of #25, too:


template<typename T> T dup(T x) { return x + x; }


The "dup" function is a bad example because (1) it fails to illustrate a difference between duck typing and other systems and (2) it is a useless function that you'd never see in a program that was not programmed by morons.

Name: Anonymous 2010-09-27 0:43

>>35,37
You can compile a dynamically typed language.  35's point may be that if you're going to go to the trouble of compiling a program beforehand, you might as well check for some common errors while you're at it.

Name: Anonymous 2010-09-27 1:04

>>41
A pretty silly point. If you're going to check for errors anyway, there's no reason to make yourself do extra work beforehand.

Name: Anonymous 2010-09-27 5:52

>>42
You may be thinking of languages like C++ and Java, where the type system requires excessive typing.  Other languages have type inference, or less verbose syntax.

When you write code, you make mistakes and have to spend time fixing bugs.  The static/dynamic choice is just a tradeoff between testing (for dynamic types) and writing type signatures (for static types).

On one extreme end of the spectrum are people like Ruby on Rails developers, who write shitty unit tests for everything and release buggy code.  On the other extreme end are academics and people developing critical software who write proofs that their code is correct, they take forever but you can trust what they do.

At the end of the day, both sides did the "extra" work of checking their code and both sides got paid.

Name: Anonymous 2010-09-27 8:18

>>43
Well it's more than just tests vs types. Type checkers like the HM one will reject some valid programs as invalid. The static/dynamic debate rest on whether or not those programs that were rejected are useful ones to be able to express. I think they are, Haskellers don't.

Name: Anonymous 2010-09-27 13:14

>>43
No, I wasn't. Even in Haskell you have to indicate some types.

Name: Anonymous 2010-09-27 16:22

I like how OCaml combines an anal type system with nice features like different operators for integer and float arithmetics.
Way to help me be productive!

Name: Anonymous 2010-09-27 18:33

>>44
Type checkers like the HM one will reject some valid programs as invalid.
Everybody always says this, but I've never seen anyone give an example.

Name: Anonymous 2010-09-27 19:02

>>47
Of course one couldn't write an example in a language like Haskell, because a program that doesn't type check isn't valid haskell. The point is that, in general, Static typechecking is, I believe, equivalent to the halting problem and therefore undecidable.

Name: Anonymous 2010-09-27 19:29

#lang racket
(let ((b (even? (current-seconds)))) ((if b sqr string-length) (if b 3 "SICP")))

Name: Anonymous 2010-09-27 19:32

>>48
The example doesn't have to be in Haskell.

Name: Anonymous 2010-09-27 19:36

>>50
If you read again, you will see that it can't be written in Haskell. That's the point.

>>49
I imagine that counts. Same with a fully general version of 'apply'

Name: Anonymous 2010-09-27 20:20

>>51
it can't be written in Haskell.
What can't be?

Name: Anonymous 2010-09-27 20:22

>>52
Do I have to spell it out? You cannot write an example of a valid program that does not type check in Haskell, because a program that does not type check is not valid Haskell.

Name: Anonymous 2010-09-27 23:53

hurrrrr

Name: Anonymous 2010-09-28 1:59

>>53
You seem to have skipped a vital phase of the discussion. We don't yet have any "it" to write in Haskell.

Name: Anonymous 2010-09-28 6:44

>>1
I'm not a programmer or anything.
Like everyone in this board. We're just pretending all the time.

Name: Anonymous 2010-11-15 0:15

Name: Anonymous 2013-01-19 23:48

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.

Don't change these.
Name: Email:
Entire Thread Thread List