Hacker News Reader

Edit: Also fuck this whole "it's so cool to shit on Java" thing. Grow up. You aren't in college anymore. You should recognize that Java fills its niche effectively, and does a decent job of being semi-fast, portable, easy to read and maintain, and safe.

The "it's so cool to shit on Java" thing served an important purpose and is probably close to being retired, but it's easy not to understand if you weren't a Java programmer some time in Java's heyday. There was a culture and a set of assumptions around Java that today you could probably only find in the most stodgy and insular corporate programming environments. I helped introduce Java into a development group and ended up hating the people and practices it infected us with. The hatred is not completely unrelated to the language (which runs on a great platform and is not a horrible language) but it would never have attached itself to the language without some of the pathological culture surrounding it.

> The "it's so cool to shit on Java" thing served an important purpose and is probably close to being retired

I don't know in which world you live in, but in the real world Java is by far the dominant platform for web services.

> I don't know in which world you live in, but in the real world Java is by far the dominant platform for web services.

I read it as meaning 'the "it's so cool to shit on Java" thing' is close to retirement, not the language itself.

You're right. I was quick to assume that the comment was yet another jab at java. Unfortunately I have to deal with developer who insist in that line of argument, and it gets really tiring.

Does that apply to any web service that meets the following criteria?

  * Created in the last 5 years
  * Built by an organization without a large Java heritage

I bet that number goes waaaay down, way quick.

For sure it may, but I wonder how many of those decisions will be regretted? Java is a fast portable language with a decent type system and a bevy of time tested libraries. It certainly isn't perfect, but modern Java is a decent development environment (and this comes from a Rubyist). I suspect only Go can match its speed, productivity, and safety.

I would bet that C# can match or exceed Java’s speed, productivity, and safety as well.

Why choose Java when you can pick from the more modern languages that also run on the JVM: Kotlin, Scala, Clojure, etc. You get all the advantages of speed and libraries without the imo bad language design.

And JavaScript is probably the most written in language in the world... doesn't mean it's great. Though, it is good enough for most things.

I always liked C# better than Java though.

That provides some interesting context to that attitude, thanks.

> I regularly wish python required some sort type indication for function parameters

You can use type annotations, either via the builtin lib or 3rd party libs!

https://docs.python.org/3/library/typing.html

> do_x() if a.y()

I feel this. You can use `a.y() and do_x()`, but I'm not sure how people would react :o

> You can use type annotations, either via the builtin lib or 3rd party libs!

> https://docs.python.org/3/library/typing.html

I know, but tragically, because I am not forced to, I never do. I do appreciate that feature though. Maybe this will be the impetus I need to start taking advantage of it.

I started doing this about a year ago and it has made me a better Python developer. Getting into the habit of always writing a type annotation was hard at first, but you quickly get used to it. It helps if you configure mypy to complain at you if the annotations are missing.

If you're starting a new project you can force yourself by running mypy's strict mode in CI.

You'll have a much better experience in an ecosystem where typing is the widespread expectation, IME.

Try an ML-family language if you haven't already - I find they combine the best parts of something like Python and something like Java. There was a post pushing F# earlier today.

> `a.y() and do_x()`

If you're happy to write it that way round, why not just use `if a.y(): do_x()`?

Against pep-8 standards. I do end up using that sytax quite a bit anyway though.

> PEP8: This document gives coding conventions for the Python code comprising the standard library in the main Python distribution.

It's fine not to follow PEP8 for your own software. It's a useful guide, not a law.

It's worth noting the second can't be used inline.

I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python. [x() if y()] if it existed, might carry an explicit else None.

On the other hand [x() and y()] does something different when y() is falsey.

>I don't know the history, but it seems like that might be one of the reasons `x() if y()` isn't allowed in python.

Maybe I misunderstood your context, but if not, conditional expressions do exist in Python:

  $ python
  Python 2.7.12 |Anaconda 4.2.0 (32-bit)| (default, Jun 29 2016, 11:42:13) [MSC v.1500 32 bit (Intel)] on win32
  Type "help", "copyright", "credits" or "license" for more information.
  Anaconda is brought to you by Continuum Analytics.
  Please check out: http://continuum.io/thanks and   https://anaconda.org
  >>> 1 if 1 == 1 else 2
  1
  >>> 2 if 1 == 1 else 2
  2
  >>> ^Z

  $ py -3
  Python 3.7.0 (v3.7.0:1bf9cc5093, Jun 27 2018, 04:59:51) [MSC v.1914 64 bit (AMD64)] on win32
  Type "help", "copyright", "credits" or "license" for more   information.
  >>> 1 if 1 == 1 else 2
  1
  >>> 2 if 1 == 1 else 2
  2
  >>>

Using nested conditional expressions to classify characters:

https://jugad2.blogspot.com/2017/04/using-nested-conditional...

Sorry, the code shown in the two Python interpreter sessions above, is not a good example. To make the concept of conditional expressions more clear, this example is better:

  >>> from __future__ import print_function
  >>> for i in range(3, 5):
  ...     print(i, "is", "odd" if i % 2 == 1 else "even")
  ...
  3 is odd
  4 is even

which can be shortened to this:

  >>> for i in range(3, 5):
  ...     print(i, "is", "odd" if i % 2 else "even")
  ...
  3 is odd
  4 is even

Now print() is printing 3 values: i, "is", and either "odd" or "even" based on the boolean condition.

That works in both Python 2 and 3.

Type annotations don't seem to actually have any effect, though? Consider:

    >>> def add(a: int, b: int):
    ...     return a+b
    ... 
    >>> add("a", "b")
    'ab'

This should be an error, even if it's a runtime error.

it's optional typing. Running it through mypy will result in an error. If you are using type annotations I don't see why you wouldn't also be using a proper IDE or testing your code.

There doesn't seem to be any interest in checking type annotations at run-time. Unfortunately, without doing so, type annotations look authoritative but are essentially just comments.

I believe Julia is an example of a dynamically-typed language which does perform such checks at run-time - including as part of its support for multiple dispatch.

Make mypy type checking part of the CI pipeline. Done.

I've been using enforce for this purpose (https://github.com/RussBaz/enforce). It provides decorators that enable type checking where wanted. This gives the advantage of migrating existing code to type checking at your own pace at least.

On a general note I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes, and that makes the whole thing feel like a hack. It's better than nothing for my use cases, but if I remember correctly both mypy and enforce have problems in common that are probably coming from the way python itself is built, such as self reference in a class definition.

> I've come across a few cases, when pushing python's type annotations to their limits, that force you to put the type names in string quotes

With pep-0563, python3.7, and `from __future__ import annotations` this should no longer be necessary. Those are some pretty detailed caveats, but I have been using it in places where I can and it is so nice.

Python has a "we're all adults here" mindset, which means it will allow you to reach into internals of libraries, ignore type hints, etc because maybe you actually know what you're doing and know the drawbacks but just need a quick solution (lots of python code is small throwaway scripts).

For actual projects you can use a static type checker like mypy.

Type annotations have no effect by default. You're free to use a tool to do compile or runtime checking though.

Indeed. My personal bugbear is lack of multiline lambdas. I use these all the freaking time in JS and it's infuriating that I can't in python.

At the end of the day it's a minor complaint of course.

I think it makes more sense in a language where you have to write callbacks all the time. I consider it a feature in Python, because by using `def` you're forced to imbue the function with meaning by providing it a name. Otherwise, it's just reading through a potentially complicated function without any context of what it's supposed to be doing.

All languages, including python, where you do a lot of asynchronous io require callbacks all the time. It's only recently python got await-support to deal with this. Single line lambdas is a real PITA when your not using asyncio and python maintainers have said they don't plan to change it :(

It also makes sense if you're trying to do any sort of functional programming.

I use Python for functional programming and I don't miss multiline lambdas. I have a large monitor, so vertical space isn't at a premium for me.

Though it doesn't take that much of an effort to just name your callback function and pass it as an argument. Python functions are first-class "objects" that can be passed around, use them!

I've always found Python lambdas to be uncanny, weird and error prone. It's kinda syntactic sugar for expression-only defs with counterintuitive scope rules. I would recommend just not using them and fall back to named functions. It's just one extra line and that way you get to name it, which is always a nice thing.

This is extremely heavyweight syntax for something I like to use as a lightweight construct. If I wanted a function, I would make something a function.

x = lambda y: <code goes here>

def x(y): <code goes here>

What's so heavyweight? A new line and a tab?

IMO lambdas are useful because they reduce mental overhead by allowing the developer not to give names to trivial functions [1]. Compare these two equivalent pieces of code:

    youngest_person = min(people, key=lambda x: x.age)

    def get_age(x):
        return x.age
    youngest_person = min(people, key=get_age)

This may not seem like a huge difference, but using lambdas scales better.

[1] Incidentally, this is the same reason why I don't miss multi-line lambdas (in Python): multi-line functions are seldom trivial.

Yeah in the context of multi line functions the overhead is

A new line A tab A return

This does not sound heavyweight to me (in that context). In the context of a single line function I see the utility of lambdas.

Guido Van Rossum and the development team didn't want the language to be functional. There is very little functional support in Python in general, besides not supporting first class functions over multiple lines.

> There is very little functional support in Python in general, besides not supporting first class functions over multiple lines.

You are confusing “first-class functions” and “anonymous functions”, which are completely different things. Python functions are first-class, independent of length.

It depends who you ask.

Some definitions of "first-class function" require that it have the same value semantics as any other first-class type, which would include a literal syntax/anonymous functions.

> I regularly find myself wanting to write something of the form do_x() if a.y() This is stupid, but I still kind of want it since do_x() if a.y() else do_y() is valid

cough maybe you should be programming in Ruby ;)

Yes, I was thinking that too. Hell, you can write:

    do_x if a.y?

Unfortunately (or fortunately, depending on perspectiven- great power and all that), Ruby allows things that Python doesn't and it's not hard to find yourself in a write-once mud bath.

I do like Python's modules over how Ruby handles them too. Ruby's import (require) is akin to C/C++, with modules as a separate idea. I prefer the style of importing exactly what you need.

But I know Ruby better so it's my go-to.

Or Perl 5. `do_stuff() if $a->y();` is a common idiom.

Or Perl 6. `do-stuff() if $a.y;` is the Perl6 version. You can even declare your variables to be sigil-less so you end up with `do-stuff() if a.y;` if you want. See my Perl6 Advent Calendar article for a quick tour of the language, available docs, with practical examples focusing on using Perl6's novel features to write a self documenting command line script.

https://perl6advent.wordpress.com/2018/12/16/

I've written code in everything from assembly to ML, Java, and Prolog. Perl6 is the only language I've used that I would "mind-expanding". The more I use it, the I realize how radical its design is.

Agreed. After indentation-as-syntax -- which I've always hated, and I've been using Python since version 1.5 -- lack of switch statement is my #1 problem with Python.

> indentation-as-syntax -- which I've always hated

What would you prefer? C-style syntax? Ruby-style `end end end`?

Literally anything that allowed easier linting, less "wait am I doing it right" regarding multi-line statements, etc.

If that is a keyword, or brackets, or whatever, I would prefer that. You can't minify or easily lint python. And you can't easily tell if there are mixed indent methods (tabs/spaces) and IDEs struggle with it vs. a simple bracket structure.

C-style syntax. I'm not a fan of using something that is inherently invisible to scope my code, and be yelled at if it's not quite right (I'm writing this in Python because I want it to be done quickly; just leave my code style alone and I'll fix it later!)

> fuck this whole "it's so cool to shit on Java" thing. Grow up.

Hey! Let people not like things, guy!

I put my pants on, go to work, pick up my heavy JVM, and crack away in the Java mines for 8 hours.

When I finally get home, tired, broken, achy fingered, and filled with disappointment for only making it to the AbstractAbstractFactory, rather than the AbstractFactoryFactory, I think I've earned a few "Yeah, with other type systems you'd be able to..." style complaints.

Greener pastures and whatnot.

> I wish python had some equivalent to the switch statement that didn't involve workarounds with dictionaries, because sometimes you just want a clean way to deal with a value that can take 7 different forms.

I am with you there. I have often wished for a C-like switch(). That said, I think the best Python leans towards the functional, so instead of a switch(), it probably would be better to come up with some kind of multi-arm match more in line with modern functional language semantics. That could also be more flexible with respect to the type of the tested expression. Maybe something akin to the Rust match syntax.

> I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare.

Well, of course Python has type annotations. TBH, I don't use them. I tend to be rather pedantic about Sphinx doc for functions, most especially __init__() constructors. Kind of old-school and manual, but it works -- make doc and read it in your browser. The other thing I do in constructors is 1) make them very tolerant of what gets passed as a parameter, and 2) be very pedantic about raising ValueError in the right place, at the right time, with a clear message.

I have a good friend that I argue with regularly -- now this guy is a compiler front-end guru -- ex-Sun senior staff level C/C++ compiler tech lead, very smart -- but we argue regularly about Python idiom. He litters his Python with extremely un-idiomatic assert(isinstance()) to check incoming parameters. I think C poisoned this man's brain with respect to type checking.

There are two things wrong with his code: 1) It raises the wrong exception, the correct exception is TypeError, not AssertError. 2) It totally breaks __int__, __float__, etc, so I can't implement those on custom classes.

In my constructors, to the extent possible, I do "type checking by re-construction" -- parameters i and p gets run through something like:

  self.i = int(i)
  self.p = PClass(p)

So if you send me a string for i or something weird that implements __int__(), everything is cool. And PClass.__init__(self, x) is responsible for turning p into an instance of PClass, leaving it alone if it already is a PClass, or raises ValueError. This idiom makes type checking as tight as you want it to be, but doesn't break Python Zen.

The pythonic way is to do duck typing, meaning don't check the params types at all. Assertions are ok to check things that should never happen. But if you're gonna put them everywhere then better use type hints. I'd use TypeError on public APIs, for private APIs is as bad/good as assert.

What I describe is duck typing, with eager authentication of duck specie. Exceptions raised at point where the greatest clarity of error message is possible.

Aspirationally, anyway.

I regularly wish python required some sort type indication for function parameters

As others pointed out, Python has optional type annotations and has had them since 3.0. They're static-only (you don't get runtime type checking from them), though, and getting what you want out of them will effectively require every single function, method and variable in not just your codebase but in every third-party dependency and all of their dependencies to be annotated.

Also, annotating "complex objects" tends to be an unreadable mess. If you have lots of functions which take complex objects as arguments, rather than a more clear list of parameters, that's probably not going to be solved by type annotations; it will be solved by rewriting the functions. In other words, you probably will not be helped by:

    def foo(o: HugeLongComplexTypeDefinition) -> OtherHugeLongComplexTypeDefinition

But you would be helped by:

    def foo(widget: Widget, operation: WidgetOperation, tolerance: float) -> Widget

> I regularly wish python required some sort type indication for function parameters, because dealing with libraries that take complex objects as function parameters can be an absolute nightmare.

Meh, never encountered this in 20 years. Typing is helpful in large projects however, and not just with complex objects.

> and safe.

Oh no! You were so close!