Why is Python hello world a one liner and does not require any Class?

[Monica Shiralkar]

Python hello world just requires I line:

print("Hello world.")

Why does it not require any class ? thanks

[Campbell Ritchie]

For the same reason as, “Come with me,” is three words in English and two in Latin. It is a different language.

[Monica Shiralkar]

But it is an object oriented language

[Tim Holloway]

No it isn't. It's a procedure-oriented language with object-oriented retrofits, just like PHP.

And it shows in all the ways you have to explicitly reference "self" where you don't in a true OOP language like Java.

[Monica Shiralkar]

Tim Holloway says

It's a procedure-oriented language with object-oriented retrofits,

Thanks. I understood that is a procedural language in which Object-oriented features have been added later. So, its hello world program does not require a Class. We can write code outside a method because it is a procedural language. Python also has a main method which is the entry point but we do not require main method for hello world. When should we use main method of Python ? I am trying to understand that although main method is the entry point , it is not required for hello world.

[Tim Holloway]

Python can operate as an old-style command interpreter, in which case there may be no "program" at all. In fact, that's one of the common ways that introductions to the language begin.

Without a main method, if you feed a python file to the interpreter, it will simply execute all the code in the file sequentially (I think it looks ahead to find function definitions, though). If there is a main method found, I believe that it may be detected during a preliminary scan and scheduled in preference to straight code execution.

There are rules for all that, although, alas, I've never bothered to formally learn them. In fact, I've been criminally sloppy learning Python, considering how often I use it.

[Monica Shiralkar]

Thanks

[Monica Shiralkar]

No it isn't. It's a procedure-oriented language with object-oriented retrofits

In most of the tutorials this information is not mentioned. What they write is that it is an object-oriented language and that it is quick to start with . Thats all.


What is the reason that python is considered as easy and quick to start with?  Is its procedure oriented nature and simple syntax the reason?

[Stephan van Hulst]

I think every language tutorial says that the language is easy to start with.

[Liutauras Vilda]

Monica Shiralkar wrote:What they write is that it is an object-oriented language and that it is quick to start with

You can get this impression regularly, umm, until something else happens.

There could be bunch of little gotchas which you overlook, and think all is well, until you run script. It may run today, but it won't run tomorrow as code may take different execution path - and that get discovered only during runtime.

Personally myself I more often than not get an impression that development time with Python versus Java takes for me longer. Partially because where I use it (as an example to write Google Cloud Functions) I can't run or execute them locally, have to deploy somewhere else first - just to figure out the data type I assumed wrongly so get an exception.

Yes, if you take HelloWorld as an example, no doubt you have to type less in order to have it running. Plus to execute python script is significantly easier as you don't need to install anything extra (in case of *nix type systems), on Windows you still have, while in case of Java you need a bit more setup which is also very trivial in case of *nix systems, while on Windows you need to play more.

[Junilu Lacar]

The fact that the Python Hello World program is a one-liner doesn't really have anything to do with it being object-oriented or not.

// Kotlin (kind of)
// previously, I wrote this:
// println("Hello, World!")
// but you have to do this (a bit of a cheat)
fun main() { println("Hello, World!") }

// Groovy
println "Hello, World!"

// Ruby
puts "Hello, World!"

There's no arguing that all three of these languages are object-oriented. At the same time, they are also scripting languages as are Python and JavaScript. This fact is really the reason you can write a one-liner Hello World program in them and not have to put all the scaffolding around that one statement that you need in Java. In a Groovy program, that scaffolding is still actually there, you just don't see it because the Groovy compiler will take care of putting it up for you.

[Tim Holloway]

One thing that became apparent very long ago is that the total amount of time/work spent on a software project is almost completely independent of what programming language you use. Except maybe for assembly language, And I'm not even totally sure on that one.

The difference is where you spend the time. Java and other strongly-typed languages delay the point where you can see results because until you have everything designed and integrated the system won't build, much less run. Scripted languages like JavaScript and Python let you see results almost immediately at the expense of a longer debugging cycle. A lot more things can lie around like rakes in the grass in interpreted systems. Sometimes years elapse before things go bad. But Murphy says that they will generally pick the worst of all possible times to go bad.

I like Java, because I'd rather embarass myself privately (during the design phase) than publicly (when it's in world-wide production), but not everyone thinks like that. Some people code-and-run leaving others to pick up the pieces. And, of course, managers like to "just git 'er Dun!" and are prone to thinking that pretty screens are equivalent to production-ready. At least architects never had to worry about anyone mistaking a scaled-down cardboard model of a building for the real thing.  

[Junilu Lacar]

I share a lot of Tim's sentiments with maybe just one slight difference:

Tim Holloway wrote:Scripted languages like JavaScript and Python let you see results almost immediately at the expense of a longer debugging cycle.

While there may be a strong correlation between being a scripting language and having to spend a lot of time debugging programs written in them, I believe there's a different causation. I think it is really a function of how much time developers spend writing tests up front (yes, I know, here we go again with the TDD) and actually thinking about good design. Ask anyone who has read Martin Fowler's second edition of "Refactoring" which uses JavaScript for its examples and they'll probably tell you that with proper tools and techniques, it's entirely possible to write well-tested, well-factored JavaScript (or any language, really) code that doesn't require a long debugging cycle later. In this regard, Tim is right: you either spend a lot of time up front writing well-factored and well-tested code or produce code expediently up front at the cost of giving up your nights and weekends looking for what you messed up later.

[Junilu Lacar]

I re- wrote:

// Kotlin (kind of)
// previously, I wrote this:
// println("Hello, World!")
// but you have to do this (a bit of a cheat)
fun main() { println("Hello, World!") }

Gah! So I was right the first time after all. You can write a true one-line program in Kotlin:

println("Hello, World!")

You just have to run it like this:
$ kotlinc -script hello.kts

[Tim Holloway]

[quote=Junilu Lacar
While there may be a strong correlation between being a scripting language and having to spend a lot of time debugging programs written in them, I believe there's a different causation.

Actually, that particular formula pre-dates test-driven design. While I had observed it myself, others had also mentioned it.

You can do TDD with both scripted and unscripted languages, anyway.

[Liutauras Vilda]

Like a lot what Tim said.

Just want to clarify slightly one point in case we have some students getting ready for an exam who reading this thread, so they wouldn't get confused.

Tim Holloway wrote:Java and other strongly-typed languages...

...Scripted languages like JavaScript and Python

Python is also strongly typed language. Like Java is. I know Tim knows, but those others who may not, there is:

statically/dynamically
vs
strongly/weakly

And these are not the same, but quite often if one, then also other is true, but not always.

Java is statically and strongly typed
Python is dynamically and strongly typed
PHP is dynamic and weakly typed.

In simple words (not necessarily technically very correct (others may correct me)):

In static typing languages you need to compile code first and only then you can execute it. Hence many stuff gets caught during compile time. While dynamic typed languages lets you runs the code and interpreter on the fly executes statements without prior compilation.

Strongly typed languages doesn't let you concatenate integer with an array let's say, it is checking basically types compatibility, while weak languages let's you do whatever you want, as an example PHP language (the worst one I have ever touched, luckily that's all my intimacy with it). You can try to concatenate an array of strings with anything else, and you might succeed to some sensible outcome, or you just succeed just get an outcome which doesn't make sense. You can compare Integer with an Array and you get something as an outcome.

[Junilu Lacar]

Liutauras Vilda wrote:Strongly typed languages doesn't let you concatenate integer with an array

This is not entirely true. It depends on what language you're talking about. There are languages, like Kotlin, where the "+" operator can be judiciously overloaded so you have List + Int semantics that are perfectly legal and sensible, like this:

# in the Kotlin REPL

>>> val numbers = listOf(1, 2, 3)
>>> val moreNumbers = numbers + 4 + 5 + 6
>>> moreNumbers
res2: kotlin.collections.List<kotlin.Int> = [1, 2, 3, 4, 5, 6]
>>> numbers
res3: kotlin.collections.List<kotlin.Int> = [1, 2, 3]

Here, the + operator has been overloaded to call List.add(Int) and then return a new List. Or rather, copy a list, call .add() on the new list, and then return the new list.

I have done similar things with a user defined Matrix class so that I can write things like this:

val a = Matrix( ... )
val b = Matrix( ... )

// matrix multiplication
val c = a * b   // c is a Matrix? -- null if a * b is impossible

// scalar multiplication
val d = a * 2.0  // d is a Matrix w/ each element in a doubled

[Tim Holloway]

Affirmative. All that you need to demonstrate Python's dynamic strong typing is to do something like this:

f = 123.45
s = f + " Hello, World!"

And watch it die. At run time. One of my favorite ways to screw up in Python.

Incidentally, IBM's PL/1 was a strong static typed language but there used to be a code example where you'd have something like "1 + '1' + 1.0 + ..." and it would compile and run just fine, but the results wouldn't even be close to what you'd expect. Because PL/1 was big into expression type conversions.

[Liutauras Vilda]

Junilu Lacar wrote:This is not entirely true. It depends on what language you're talking about. There are languages, like Kotlin, where the "+" operator can be judiciously overloaded so you have List + Int semantics that are perfectly legal and sensible, like this

Well, I see what you are saying, concatenation probably wasn't the best example given by me to demonstrate what I wanted to say, as well as I didn't account operator overloading, however, that's not exactly what I had in mind, in case of Kotlin it just appends an integer to a list, but doesn't treat both operands as presumably equal/same things in certain operation, that is what I had in mind. Not sure I'm still clear. But thanks for clarifying this further - lots of literature using static/dynamic; strongly/weakly interchangeably, which really are different things.

[Junilu Lacar]

Liutauras Vilda wrote:Not sure I'm still clear. But thanks for clarifying this further - lots of literature using static/dynamic; strongly/weakly interchangeably, which really are different things.

The distinction can get pretty murky and the lines blurry. I'm not even sure I can articulate it correctly off the top of my head. I like this article though, which seems to do a pretty good job at explaining the differences: https://en.hexlet.io/courses/intro_to_programming/lessons/types/theory_unit

[Monica Shiralkar]

Thanks.I think there are 2 reasons why it is said that  learning and development in python is quick . In python one has to write lesser code and in python we do not have to first compile and then run. We can just directly run.

[Monica Shiralkar]

Tim Holloway wrote:
I like Java, because I'd rather embarass myself privately (during the design phase) than publicly (when it's in world-wide production), but not everyone thinks like that.

How is it so ?

[Tim Holloway]

There are several standard software lifecycle stages: design, coding, debugging, production, and support. That's pretty much true no matter what programming language you use. And, from my experience and reports I've heard from others, the total time spent over the application lifecycle is pretty much the same, regardless of the language used. Much to the annoyance of managers who want a "silver bullet" platform that makes it all shorter and cheaper and have been searching for one since before I entered the profession.

The main difference is what parts of the lifecycle you spend the most/least time in. In scripting languages like JavaScript and Python, you can do a sketchy design, scribble out some code and have something that "runs" fairly quickly. The complaint I have here is that if the architectural profession worked like software, architects would make little cardboard models of bridges and buildings and their employers would expect those little cardboard models to be production by next week, since all the visible parts are there, even though the real work - scaling up, using construction-grade materials, testing, and so forth were yet to be done.

Compiled languages with tight bindings, on the other hand, require a more detailed design and more rigorous coding before you can even make them compile. The payback is that since so many errors are caught and dealt with on the developer's desktop, they won't be around to blow up the production system. So with a language like Java, I can do stupid things and only myself and the compiler will know, With a language like Python, I could, as I've said, literally sneeze in the middle of saving a program module, hitting the keyboard and injecting random characters, and if it's not caught by upstream testing or review, the garbage characters might still be there polluting a critical but rarely-used function such as leap-year tax filing. And when something blows up in production, I may be the last person to find out, not the first and only one! And everyone who found out before me will have something bad to say. Including, perhaps, millions of customers.

[Monica Shiralkar]

Tim Holloway wrote: with a language like Java, I can do stupid things and only myself and the compiler will know, With a language like Python, I could, as I've said, literally sneeze in the middle of saving a program module, hitting the keyboard and injecting random characters, and if it's not caught by upstream testing or review,

But wouldn't even in case of Python,for those characters the IDE will show it as "Unresolved reference" and thus prevent us from proceeding?

[Tim Holloway]

Monica Shiralkar wrote:But wouldn't even in case of Python,for those characters the IDE will show it as "Unresolved reference" and thus prevent us from proceeding?

Who said I'm using an IDE? I usually edit Python with Emacs. For quick changes I use Nano.

In any event, I doubt that the best of IDEs will reliably be able to detect unresolved references in dynamic languages as well as static languages can allow. But in Python I can save the following:

import getpass, imaplib
import email.utils
import os
import time
from datetime import tzinfo, timedelta, datetime, date
import configparser

config = configparser.ConfigParser()
#config.readfp(open('defaults.cfg'))
config.read(['mailclean.cfg', os.path.expanduser('~/.mailclean.cfg')])

EVERYBODY = ''

imapserver= config.get("mailserver", "server")
user= config.get("mailserver", "user")
password= config.get("mailserver", "password")

M = imaplib.IMAP4_SSL(imapserver)
M.login(user, password)
M.select("INBOX")

def fix_date(dte):
    """
    Fixup elance dates, which have no TZ offset and use number, not name in month
    return fixed date
    """
    part = dte.split()
    mno = int(part[2]) - 1
    mm = ['Jan', 'Feb', 'Mar', 'Apr',
          'May', 'Jun', 'Jul', 'Aug',
          'Sep', 'Oct', hifew6*( (gesundheit)
    part[2] = mm

...

And until something actually compiles it, nothing will be seen as invalid. And the compiling is done at run time if you're not using a compiling IDE.

[Monica Shiralkar]

Yes. If one does not use IDE,  such problems would not be detected until runtime whereas in Java it will be detected at compile time itself.

[Jesse Silverman]

Tim's points are the reasons I don't like the idea of checking anything I haven't both tested and Linted into production in Python.
A particular Lint question was posted separately...