All the things I hate about Python - <AUTHOR> https://medium.com/@natemurthy/all-the-things-i-hate-about-python-5c5ff5fda95e <comment><USER3> This starts off with a misunderstanding of what "strongly typed" means. Python is strongly, but dynamically typed.

Static typing means you know the type of something at compile time. Dynamic typing means you don't. The upside to dynamic typing is that the compiler doesn't have to prove much about your program; the downside is that it can't really prove much of interest either. Strong vs weak typing is about how much your language is willing to fudge types in order to make an operation succeed without errors -- be it the intended result or not. Both static and strong typing tend to make errors be more obvious sooner. Both dynamic and weak typing tend to require less boilerplate to make your program do things.

Python doesn't know the types of things in advance (dynamically typed), but it is very picky about which types are allowed to interact (strongly typed). Even in cases where the answer is obvious, like str.join, you still have to make everything strings: "".join([1, 2, 3]) will fail.

To demonstrate why these are orthogonal, consider the other cases.

Haskell is strongly and statically typed. A program that adds a string and a number together will be rejected at compile time because the compiler can prove it's invalid.

C is weakly and statically typed. A program that combines a string and a number may be accepted by the compiler, who interprets the number as, I dunno, a wchar_t or something. Another example of weak typing is how C allows (heck, encourages) pointer arithmetic and untagged unions/structs.

JavaScript is weakly and dynamically typed. A program that adds a string and a number together will, at runtime, convert the number to a string and then concatenate the two.

<comment><USER4> You're correct but this barely changes the authors points:

"It's virtually impossible to statically analyze"

and

"In Python a good amount of errors are discovered at runtime"

<comment><USER3> The rest of the points are silly rehashes of arguments as old as Emacs v vim, but sure, let's go there too. We've done empirical research to see if this matters. Charitably, the results are "inconclusive"[0].

> The first glaring issue is that I have no guarantee that is_valid() returns > a bool type.

You can name functions ridiculous, unhelpful and misleading things in any language. The very fact that you know to expect a bool undermines the point: clearly, despite not having static types, a human managed to make a pretty reasonable assumption about what a piece of code was about to do. Just because the compiler can check that is_valid returns a string doesn't mean that hat's magically a useful thing to do.

> The fact that I cannot, in the absence of perfect test coverage, verify the > syntactical correctness of someone's code is a big red flag.

Syntax errors are caught by the compiler. Semantic errors aren't caught by the best type systems. At best, type systems are a way to encode a bit of the semantics so that the compiler can prove things about it.

> To improve static type checking in Python, developers made libraries like > jedi, pytype, mypy, and toasted-marshmallow, but they are often not used in > most projects because they do not belong to the standard toolchain

I can not imagine the author actually used jedi and believes this. That's... not how jedi works. I also don't know what to do with the argument of "oh, you have an optional static type system but people don't use it because it's annoying, this is why we should use a mandatory static type system" other than shrug.

I like types! I think there are great arguments for types. I like the idea of being able to have a type system prove that certain bugs can't happen. This adds nothing but FUD and no new insights.

[0]: [https://danluu.com/empirical-pl/](https://danluu.com/empirical-pl/)

</comment></comment></comment><comment><USER5> I love Python, and use it often. It's huge in many industries due to the ease in which people from various backgrounds can learn it. However, I agree whole heartedly with the article. Python does not scale, performs poorly and is unreliable at run time.

I think this is true for many second generation languages, not just Python. Perl, Ruby and JavaScript are really no different. None of these languages were designed to scale, be cloud oriented and perform close to C. Thus, many developers complain of 'hitting the wall' and try other languages because their tools were not intended nor designed to do these things.

I also think Go (and languages like it) which were designed to scale, use the cloud, be safe and fast (performance close to C) are the solution and the future. Here's a quote from Ian Lance Taylor, ___" Go was deliberately built from the start to support large scale programs implemented by hundreds or thousands of different programmers. Those kinds of programs are written at Google, and Go was designed to be used to write programs at Google."_ __

More from Ian on this topic here -[https://www.quora.com/Will-the-Golang-code- become-unmaintain...](https://www.quora.com/Will-the-Golang-code-become- unmaintainable-for-large-code-bases)

</comment><comment><USER6> > There is no short answer as to what is fully going on here, but simply put, > Python modules are packaged either as a Wheel or an Egg

This is a false dichotomy -- there are actually many different ways to package a Python module, including source distributions (sdists). These are just the two most well-known types of _built distributions_.

> The numpy module is a wheel, i.e. it is a source distribution that depends > on a handful of system libraries — gfortran, blas, lapack, atlas — to > compile properly.

This is not correct, a wheel is specifically _not_ a source distribution, it is a _built distribution_. The dependency on platform-level libraries has nothing to do with what type of distribution it is.

NumPy publishes a lot of wheels for a given release ([https://pypi.org/project/numpy/#files](https://pypi.org/project/numpy/#files)) each of which is platform-specific, since they are pre-built (pre-compiled) for a given platform.

In the event that a built distribution isn't available for your platform, that's when pip falls back on the source distribution, which requires the build step (hence the dependency on gcc or clang).

</comment><comment><USER7> To me, the core points seem like table stakes knowledge that one should have before jumping into development with ANY language, not just Python. Every language is a tool that is good at some things and not good at others. Cue the standard if all you have is a hammer, every problem looks like a nail.

A few core things:

The GIL problem is frustrating. I generally just try to avoid writing threaded code and instead execute calls asynchronously or run parallel instances and work with Celery or something similar. For web applications, this tends to work well enough for me personally but this is definitely a valid issue.

Python2 vs Python3 is sort of a done deal at this point, in my opinion. I was a big holdout on moving to 3 for a while but, for the past couple of years, I haven't had more than 1 or 2 cases where I had _serious_ issues. I don't have to deal with legacy codebases though.

On a larger note, I would say that this all points to the fact that it is easy to do things the "wrong way" in Python. The accessibility of the language is great, but it is not without its issues if you go in expecting it to be a fenced-in playground with batteries included (to mix metaphors).

<comment><USER8> The "GIL" problem is so over exaggerated for most problems. A significant amount of threaded code is IO bound and in most of those cases the GIL gets out of the way. Checkout the cpython code around the calls to things like select, poll, epoll. If you are needing to do high performance number crunching across multiple cores, then yeah it's a little more work, but it's gotten easier and easier to write some C libraries for that or leverage something like numpy.

<comment><USER7> I would agree it's over-exaggerated. In my day to day work, the GIL has rarely, if ever, been the performance bottleneck. It usually traces back to something outside of Python (e.g. a slow DB query or a slow API call) or to something that has been implemented in python in an inefficient way (e.g. writing something O(n^2) when if you read your algos 101 book or even just searched stack overflow you could find an O(n) solution).

I also think that the whole "drop down to C argument" is sometimes viewed as a cop-out when criticizing python, but I personally believe that being proficient at high-level and low-level languages, knowing their strengths and weaknesses, and transitioning between them when it makes sense is stronger than just using purely high OR low-level. It's sort of like having multiple gears on a car: you need all of them, and they are all useful and most opportune in different scenarios.

</comment></comment></comment><comment><USER9> > However, Python does not have a real privacy model.

> This is unsettling if you're coming from a Java or C/C++ world and are > expecting access modifiers

It's unsettling to a lot of people, but so what? I still don't see a solid use case for where member access (not "privacy") is a good idea. Python is one of the only languages to get access modifiers right (convention), imo and I don't even like Python.

You could implement some "privacy" with a lambda closure (which gets increasingly complex), but that's one more technique that lambdas are ill- suited for.

<comment><USER10> The author makes a lot of strong statements based on their opinions. I wrote a bit about their dynamic/weak typing gaffe in another top-level comment.

> lambda closure

Just FYI (not intended to be mean or anything), in formal PL theory this phrasing doesn't make sense. A closure is the pairing of an anonymous function (a "lambda") with an environment. Python's "lambda" is really just a lambda --- it is not a closure. This is revealed in the common pitfall where you try to create a list comprehension using a lambda to generate interior values.

<comment><USER9> The idea is to create a lambda that's sole purpose is to act as a closure for member access restriction. I'm not sure how that could be misinterpreted, but here's your prize.

<comment><USER10> I guess my point was that you should have just said "closure" instead of "lambda closure", since that phrasing doesn't make any sense in a formal context. Lambdas and closures are different things entirely. I really wasn't trying to be patronizing or anything; I was just trying to offer information in case you found it interesting, but I guess I missed the mark there. My apologies.

</comment></comment></comment></comment><comment><USER11> > Python is viewed as a ubiquitous programming language; however, its design > limits its potential as a reliable and high performance systems language. > Unfortunately, not every developer is aware of its limitations.

Hammer is viewed as a ubiquitous [sic] tool; however, its design limits its potential as a reliable and high performance drill. Unfortunately, not every carpenter is aware of its limitations.

<comment><USER12> "Ubiquitous" is spelled correctly. Why the "[sic]"?

<comment><USER13> > "Ubiquitous" is spelled correctly. Why the "[sic]"?

For what it's worth, '[sic]' doesn't necessarily mean "that was spelled incorrectly", only, literally, "thus": i.e., "that's the way it was in the original; don't blame me." As such, it can be used to indicate misspellings or 'misconceptualisations' ("I know that it's the wrong word, but it's the one that was there"), as nmyk ([https://news.ycombinator.com/item?id=17484468](https://news.ycombinator.com/item?id=17484468)) indicates.

<comment><USER14> To expand on this excellent description, when JadeNB claims that "sic" literally mean "thus", that is because "sic" is the Latin adverb meaning "thus". Some people think that "sic" an initialism for "spelling is correct".

</comment></comment></comment></comment><comment><USER15> > Ok, so "hate" is a strong word, but hopefully this click-baits enough folks > into reading this article with a clearer, more rational and unbiased > demeanor than what the title suggests.

Self-aware clickbait is the worst kind of clickbait.

<comment><USER16> All clickbait is self-aware. People aren't not doing it by accident.

<comment><USER17> People can very well do it because they like fancy titles, or leaving things unspecified, or puns, or whatever, and not to drive visitors to their website.

In fact, before the web, authors have long used fancy titles for articles that you had to buy the magazine or newspaper to even read, so they had no advertising-like value to attract unsuspecting readers.

</comment></comment></comment><comment><USER3> The author complains about CPU-bound performance and then mentions PyPy but claims it's ecosystem is barren enough that the point stands. This claim is presented without evidence.

In practice it doesn't really show up: the cases where code is actually CPython-specific usually imply all the work is being done in highly optimized C bits. Hence, those programs, despite being run on CPython, aren't CPU-bound.

Finally: while this FUD is really pernicious because it used to be hard/impossible to get scientific code like numpy to run on PyPy, that hasn't been the case in a long time. Right now you can just pip install numpy and it'll just work.

<comment><USER18> It will bite you when you don't expect it. When i work, we had a dev write a IO trace playback engine in Python to do some IO performance testing. We then deployed it on various platforms and got very strange results - eventually I noticed when TOPing the node, the CPU was pegged at 100%, so this wasted about 2 months time of about ~4 developers

<comment><USER3> What was the root cause?

<comment><USER18> Wasn't worth taking the time to figure out, since none of us were expert level in python and we only needed a one-off profiling tool. I rewrote it in Julia, which killed the problem.

<comment><USER3> So you have no idea what it was but you're certain it's Python's fault?!

<comment><USER18> Given that it was about 150 lines of code and I did a fairly straightforward rewrite in a performant language in about a day, and the performance was acceptable, yes.

</comment></comment></comment></comment></comment></comment><comment><USER19> The typing, encapsulation, and packaging issues are features of the language which have benefits and tradeoffs. The author of the article seems to balk at them because they aren't what he is used to. Re: typing in particular, gradual typing is something that's slowly becoming viable, and I think it's great.

The python 2 vs 3 issue isn't really an issue if you're starting with the language. There was a time where lots of big libraries were only supported by python 2, but that's definitely not the case any more.

OTOH the build system is definitely a common pain point, and the GIL forces you to use other services (e.g. redis + multiprocessing) to achieve horizontal scaling which is unfortunate. And of course python's crappy performance is something anyone looking at languages should be aware of.

</comment><comment><USER20> I've used Java/C/C++/Ada/Perl/Go and most recently Python all professionally in one aspect or another. I settled on Python.

So being a professional Python/Django coder, I was aware of all these issues. And yet, those issues do not seem to stop the Python train from moving forward.

A couple of issues to note in his article: Everything he says is true, but the conclusions are mostly false.

1\. Optimizing databases and data access are the number one scalability issue. It's the hardest thing going from a monolith to a microservice architecture. Goroutines, threads, etc. don't solve that for you.

2\. Threads are terrible in any language (except Erlang maybe), and reliable code cannot be used with primitive thread constructs. Goroutines are good enough, sure. Also python asyncio. But not threads. I've seen production systems that no one could debug, because 3000 threads ran amok, thread deadlocks, race conditions, etc. And you can't unit test threaded code effectively either.

3\. All software has multiple build systems. C/C++ and autotools, CMake, Scons, Waf. Java and Ant or Maven or Gradle or whatever. Go is sane for the most part, until you get to dependency management -- goglide, govendor, etc.

4\. Strongly typed, statically typed systems (Java, C++) usually aren't. Usually people rely upon that as a crutch to think they don't have to worry about types, until they see NullPointerExceptions (java) or segfault (C/C++) in production.

5\. Python code is only as reliable as the person who wrote it. But that's true of C/Java/C++ etc. People have to understand where the pitfalls of a language are, and that's usually documented in coding standards or style guides.

</comment><comment><USER21> My main beef with python is its packaging management.

It's a clusterfuck of half-baked, non-standard, spaghetti code approaches.

The Zen of Python says _" There should be one-- and preferably only one --obvious way to do it."_ Python package management makes that in to a joke.

<comment><USER22> That's because package management is an extremely hard thing to do if you're only trying to control one part of a system and have it work magically in different environments. And so strangely enough programming language people writing their own toy-town package managers get it wrong again and again and again.

<comment><USER20> It's worth noting that autotools for building C/C++ was so broken that ESR declared that SCONS (written in python) was a much better way to build C/C++ code.

</comment></comment></comment><comment><USER23> after 5-6 languages and coming back to Python I would say the worst things are

\- large and inconsistent stdlib api,

\- extremely wordy but somehow still vague documentation

\- overwrought build/packaging system (although tooling has improved)

\- endless runtime gotchya debugging in production

\- almost all the baggage of OO boilerplate but none of the benefits of type- checking.

\- half-baked functional paradigms

<comment><USER24> Great list!! Captures my thoughts and complaints perfectly after coming back to python following a few months in typescript land.

Although I would add the incredibly slow process start time to the list as well.

</comment></comment><comment><USER25> Totally agree with this person's assessment on types.

I took over a smallish half-completed web application written in python a couple of years ago. Nothing major - simple business-y analytics/data viewing app with some fancy charts and tables etc - perhaps a couple of thousand lines of code interfacing to backend database unique to our business. It had some tests, but nowhere near 100% coverage. I needed to finish it off and then get it into production.

Long-story short, trying to understand someone's half-completed python and make changes to this was a HUGE nightmare for precisely the reason the article outlines: python expects _you_ to remember _all_ the minutiae of all the code you are calling. If you cant remember, then you need to suck it up and pick your way through the code and mentally keep track of what is going on at every stack frame.

So instead of thinking about the _actual problem_ you're trying to solve, python forces you keep track of all the little bullshit that you shouldn't need to care about. And even then, you cant be 100% sure you got it right until you exercise that code (either through 100% test coverage, or - <USER2> - at run-time at 3am on a Sunday when a user in Japan logs on).

So far from being productive and "easy to use", python for us was a nightmare of low-productivity and frustration in only a very small application being worked on by just 2 or 3 remote developers. I cant imagine the levels of pain and suffering for larger projects & teams!

The "solution" is apparently extensive & specially crafted comments that specifically explain the types used (that of course needs to be kept up to date) - I find this fairly odious (why not just use a typed language if you _need_ to put the types in the comments?!)

I know now that Python is looking at type hints as part of the language (PEP 484 - [https://www.python.org/dev/peps/pep-0484/](https://www.python.org/dev/peps/pep-0484/)) that should help a lot.

Still, its not all bad. As a result of the pain of this application (which incidentally was damn slow in production due to the processing we had to do on the data in the python backend before we sent it to the browser), we decided to learn golang and use that for future work instead and have not looked back.

Golang has the same feeling of fast-paced "throw things at the screen" productivity, but is obviously typed (so you know about errors before your users do) and orders of magnitude faster.

<comment><USER26> .. sorry to hear about the frustration, but almost all of these are ordinary problems with application development. Maybe the original developer made a mess, but that is ordinary too.. if you have a short-list of hmm .. ways to solve typical problems, in a workflow you like, in a language and functions you like.. then you can bring those to the new efforts.. production technical engineering groups will sometimes just bid to remake the whole thing, using their own ways, for exactly these reasons.. but individual developers rarely have that option.. chin up!

</comment></comment><comment><USER18> > there is no question that type safety matters for building and maintaining > large-scale distributed systems in the enterprise.

Some of the largest-scale enterprise distributed systems, as in, at the telecoms level, are written in erlang, which is dynamically typed, and highly reliable.

<comment><USER27> Aren't Erlang variables immutable by default? I find that makes a huge difference to the reliability of a program.

<comment><USER18> If I had to choose between immutable and dynamic versus mutable and static, I will pick immutable and dynamic.

</comment></comment></comment><comment><USER28> Hi everyone, so I'm the guy who wrote this article. I'm sharing a video recording of George Hotz writing some Python code. Note his reaction at 5:55

[https://www.youtube.com/watch?v=7Hlb8YX2-W8&t=355s](https://www.youtube.com/watch?v=7Hlb8YX2-W8&t=355s)

His outburst is an emotional manifestation of the different sources of frustration I've had working with Python that I've tried to document.

A common theme I've seen in responses is that many claim that I've mistaken Python as a weakly-typed language countering that it is indeed a strongly- typed language -- obviously an argument of semantics. I'll define a "strongly- typed" language as one where it is trivial to identify the type signature and definition of any function or variable in a program. In Python, this is non- trivial.

FYI, this article is also cross-posted on:

[https://news.ycombinator.com/item?id=16337435](https://news.ycombinator.com/item?id=16337435)

[https://news.ycombinator.com/item?id=16371338](https://news.ycombinator.com/item?id=16371338)

[https://news.ycombinator.com/item?id=16411765](https://news.ycombinator.com/item?id=16411765)

<comment><USER14> I have exactly the same reaction to C#, C, Forth, Pascal, Prolog, etc: regardless of the typing strength or compiler nitpickiness there will be scenarios where stuff doesn't go as planned because I didn't understand the problem domain sufficiently, and these errors serve to enhance my understanding of the same.

Regardless of language, x -> a + 1 is not going to work if a never has a value. In many cases handling "a doesn't have a value" is the wrong way to address the problem, because the problem should be solved as "figure out why the data collection didn't work, and propose a strategy for handling our dataset when either a value is missing or is provably wrong."

As an example one might assume that a video feed has exactly as many frames per second as it says on the tin (eg: 24fps will have exactly 24 frames for each second of video) but in reality there will be missing frames due to data corruption, or even a mismatch in clock speeds meaning that over 100 seconds you have 2398 frames instead of 2400. How do you handle the missing two frames? The problem is there are no frames missing, it's just that they were never there to start with, and frame 1237 of another source has no direct equivalent in the slightly-faster stream. You might alter the clock for processing, duplicate one or two frames, use interpolated frames, or otherwise process the various sources so that you get a consistent synthesised data stream with which to do further processing.

Strong typing doesn't help solve real problems.

</comment></comment><comment><USER29> Python is the worst programming language, except for all the others I tried (Fortran, C++, Java, Scala, Clojure, PHP, Ruby, Mathematica, IDL).

But seriously, the points raised by the author are valid. However despite this Python is still a pleasure to use. In addition the author fails to mention some newer things, which can help with some of the problems Python has:

1\. Python Type annotations [https://docs.python.org/3/library/typing.html](https://docs.python.org/3/library/typing.html)

2\. Please use the concurrent futures package for multithreading: [https://docs.python.org/3/library/concurrent.futures.html](https://docs.python.org/3/library/concurrent.futures.html)

3\. For distributed concurrency please use Dask: [https://dask.pydata.org/](https://dask.pydata.org/)

4\. Please use pipenv for package management: [https://docs.pipenv.org/](https://docs.pipenv.org/)

5\. For performance, have you tried numba: [https://devblogs.nvidia.com/seven- things-numba/](https://devblogs.nvidia.com/seven-things-numba/)

<comment><USER30> Ugh the Numba claims. It still has a high function call overhead from Python and is type restricted. I couldn't pass functions to SciPy ODE solvers without a 10x overhead of doing things directly in Julia and C++, so while a ton better than straight Python it was still bad.

Also there are very few packages actually using Numba. It seems that more people like to talk about possibly using it than actually use it.

</comment></comment><comment><USER31> I am surprised nobody mentioned python's weird scoping rules for local variables. It bit me countless times.

<comment><USER20> You mean:

      def myfunc():
        try:
          while x in someiterator():
            a = x
            dosomethingwith(a)
        except:
          # Does a exist here or not?

If someiterator() raises then a won't exist in the function block. Otherwise it will.

</comment></comment><comment><USER32> I teach intro programming using python, and use it regularly for various projects.

But I agree with the author's central point that the language has a number of issues.

He mentions the python2 vs python3 issues, but doesn't discuss what is to me the biggest problem of all that: there is no standard simple way to identify within the code what version of python it needs or is written for. Coming originally from the perl world, that has always seemed like a significant oversight.

Nor does he mention several of my other biggest issues with the language, such as the arbitrary assignment of some operations to global functions (i.e. a=[3,2,1]; len(a)) while others are method calls (i.e. a.reverse()) which return nothing. And then there's list(reversed(a)) and all the iterator awkwardness ...

Explaining to students learning programming for the first time why neither of these do what they expect is never fun.

        >>> print(a.reverse())
        >>> print(reversed(a))

<comment><USER33> Yes, much of what's wrong with python in one line of code: >>> reversed(a) <listreverseiterator object at 0x7f1c3bf94310>

who needs a __str__ method for listreverseiterator anyways. they cherrypicked the worst of the Java world: Unreadable names and batteries excluded. yuck!

</comment></comment><comment><USER34> The thing I hate about Python related article: A big snake. It scares me every single time. Please don't put a big snake in your articles

</comment><comment><USER10> > Python is considered a weakly-typed or dynamically-typed programming > language.

This isn't right. Weak/strong typing is on a different axis than static/dynamic typing.

Python is strongly typed. There's no implicit conversion among types (which is one marker of weak-typedness). For proof, consider:

      >>> 1 + '3'
      [...]
      TypeError: unsupported operand type(s) for +: 'int' and 'str'

_Strongly typed_ means that the types are protective, in a way. You put a value in a box labeled X and that's it — you can only treat it as an X from now on.

In a weakly-typed language, if your function expects an X and you give it a Y, well, it'll do its best to make due.

Many people think that because Python is dynamically typed (i.e. you can pass anything anywhere without compile-time restrictions), that it must also be weakly typed. This is simply not the case. If I write a function which expects an integer and I give it a string, I'm going to have a bad time despite the fact that the code "compiles" and only fails at runtime.

\---

Edit: I've read further, and the author actually uses their lack of knowledge on this subject to portray the Python community as being willfully misleading in their promotion of the language:

> Python markets itself as a dynamically-typed programming language, similar > to Perl, Ruby, or JavaScript. The word "dynamically typed" has a positive > connotation, more so than "weakly typed." Conversely, the word "strongly > typed" sounds more positive than saying "statically typed." Diction matters, > because proponents of different camps will select a word-choice that > reflects their bias of one programming language over another. Python is both > weakly-typed and dynamically typed, which contrasts itself to languages like > Java, Scala, C/C++, and Go which are strongly-, statically-typed.

C is statically typed, but it is also _weakly_ typed. You can treat any value as any type if you so wish, either by explicitly casting or by removing checks for implicit casts during compilation.

I'm going to finish reading this article, but... I don't think I respect this author very much, based on what I've seen so far.

\---

Edit 2: While the author's points would be valid by themselves (GIL, build toolchain, dynamic typing), the over-abundance of negative rhetoric shows that the author was merely interested in writing a smear article of Python, essentially. I think it's a pretty weak article overall, and would have been aided by a more fair comparison with notes about _why_ some of these design decisions were made (or at least a less-slanted writing style).

<comment><USER35> It's also in the Wikipedia page about python that it is _not_ a "weakly typed" language. It's literally in the resume box in the corner : "Typing discipline : Duck, dynamic, strong".

Edit: I was going to mention the author's confusion, but OP did it in their edit.

Edit 2: The author is "Staff Software Engineer at Tesla" ? And he doesn't know C pointers ?

<comment><USER10> It's worse than I thought. If you see my edit, I found that the author used their complete ignorance of the (strong/weak)/(static/dynamic) distinction to invent a claim of willful misdirection on the part of the Python community. Not only did they not do their homework on the topic, but they tried to portray people in a negative light to further their narrative. I find that incredibly dishonest.

</comment></comment></comment><comment><USER36> It aggravates me the abundance of scientific/mathematical packages that exist for Python, because of all of the language shortcomings that this article details.

No doubt your typical Math Ph.D. type doesn't want a language with a step learning curve to implement their expertise, so what to do?

Perhaps everyone could at least switch to Go,a language which (as I understand) provides for some basic static type safety, good performance, etc.

I spent six months working in Python a while back and I'll be intent to avoid it from now on.

</comment><comment><USER37> One thing not mentioned by anyone yet, that kinda annoys me is the fact that Python libraries use different naming conventions. Even though PEP 8 has existed for 17 years now, there are many examples where I see lower_case_with_underscores mixed with lowercase and camelCase in the function names.

I know that many libraries and Python standard lib itself predate this PEP but I don't understand why Python 3, which broke backward compatibility anyways, did not fix that at least in the standard library.

<comment><USER38> Oh yes! Or at the very least created aliases with the correct casing.

</comment></comment><comment><USER39> 1\. Significant whitespace.

If I had a dollar for every time a bug was introduced in Python code due to incorrect indentation during code refactoring, I would retire already.

<comment><USER40> Then you're not using an editor/IDE which is smart enough to refactor things for you.

</comment></comment><comment><USER41> All points are at least semi-valid concerns.

However, what is the cost of addressing them? Slower development (core lang and ecosystem). Less use in niche fields. Less flexibility to adapt to new challenges.

Python is a rusty toolbox that's been put together over 27 years.

You know why it's still around? Because people can use it to do the things they want to do.

Fixing all the warts would give us the language we need now... in about 15 years. Which would by then be useless.

</comment><comment><USER42> My take:

\- The indentation based syntax: it can easily trip you up when moving big blocks of code around. You want to put this if else block somehwere else, hope you get a syntax error, because you can get sth. that seemingly works but does not do what it's supposed to do. Also sometimes finding where you are can be difficult.

\- Dogmaticism: a big thing in the community. They'll wait 20+ years until they add string interpolation, a feature common in many similar languages. They'll wait 20+ years until they start to realise having expression equivalents of statements is useful.

\- Breaking syntax: new syntax is added in what seems to be minor releases, so you either avoid new syntax to be compatible w/ all the 3.* interpreters, or you need to expressly avoid certain interpreter versions. And there's no equivalent of Perl's "use v5.something;" so you need to write code juggling multiple supported versions.

Still I think it is a nice language to have in your toolbox for the vastness of the stdlib and the available 3rd party packages.

</comment><comment><USER43> Oh yes, python packaging sucks. That may not be well understood. But the languages that handle distribution very well are just a few, that i know of (jvm based, .net based, go, possibly js with all the tools that exist) and there'll be some that i don't know. But for most languages, distribution of a software with dependencies is a great pain.

</comment><comment><USER44> lazy article. dude wishes python was java. also, it fails the snake-test: python is named for Monty Python's Flying Circus, not the snake. anyone who uses the snake is not clueful.

<comment><USER45> Well, to be fair, Python's logo resembles a snake more closely than John Cleese.

</comment></comment><comment><USER46> Hate those things all you'd like, but that won't stop you or others from using it and doing so regularly. None of these points are show stoppers for many scenarios. That's good enough. Python is the best second language for everything and first language at many things.</comment>


Kill the settings, build opinionated software - <AUTHOR> http://flyosity.com/iphone/kill-the-settings-build-opinionated-software.php

<comment><USER4>
      Some people argue software should be agnostic. They say
      it's arrogant for developers to limit features or ignore
      feature requests. They say software should always be as
      flexible as possible.

      We think that's bullshit. The best software has a vision.
      The best software takes sides. When someone uses
      software, they're not just looking for features, they're
      looking for an approach. They're looking for a vision.
      Decide what your vision is and run with it.

Well, I, in turn, think that's bullshit. IMO, the best software conforms to the way the user works, rather than trying to force the user to work in a way that's unnatural to them.

The arguments against a confusing preferences pane and the arguments for sensible defaults in no way contradict the notion of making software than is flexible enough for power users. Poor UI design (3 different places to set prefs?) is orthogonal to the issue of whether or not something should be configurable.

Power Users don't matter? Maybe for certain classes of consumer applications that don't face a steep barrier to adoption in the first place. But for some apps, it's the power users who are the early adopters, who first begin using and evangelizing for the software and without whom it would never catch on in the first place. Do you really want to piss those folks off?

Make the damn "advanced preferences" pane more or less hidden (ala, about:config) but document the shit out of it and make sure it's at least there for the people who _do_ care.

<comment><USER5> Every piece of code or bit of functionality you write has a cost of ownership to your business.

Every preference requires more testing to make sure that other things don't break as a result of a user changing an obscure setting.

If you don't mind having to write test cases for thousands of permutations of possible settings, go ahead and let your customer change everything. A simple product, however, is far easier to maintain.

<comment><USER6> Obviously, the simpler the product is, the easier it is to maintain. But as the product gets simpler and simpler, it becomes valuable to an ever-smaller pool of users, all of whom have differing needs. Obviously it's not as simple as "just build it simple." There's a delicate equilibrium that must be maintained.

<comment><USER7> While they're often linked, it's important to remember the distinction between "Simple Codebase" and "Simple to Use". The latter is much more important in most cases than the first, and sometimes it can take very complex code to make something as simple as possible for the user.

The simpler something to use, the bigger the pool. The fewer the applicable use cases, the smaller the pool.

</comment></comment></comment></comment><comment><USER8> Here's a little anecdote: Years and years ago, in a moment of free time, I added a bunch of silly settings to my software (EasyBCD, now with 7-10MM+ users). It had almost no users then, and I just added these options to "fill up" the empty preferences dialog. A year or two later, I removed a couple, and the complaints could be heard around the world.

The features, you ask? They really are ridiculous: Save the window size on exit. Set the default size of the UI text. Set the default font of the UI text. Open in "advanced mode" by default. Open to a particular page.

None of these features really saves a user more than a click. Some of them are purely aesthetic. But their popularity - which I greatly underestimated - <USER2> incredible. Till now, people file bugs when their favorite "silly preference" ends up resulting in odd behavior. And they _always_ catch on immediately when I change something there.

Sure, it's hard work (read: boring, time-consuming, donkey work) to maintain these options. But I think they're part of the reason EasyBCD has succeeded.

(Note: EasyBCD is a software most people install once and never use again. It's definitely not something you would use on a daily basis. But people LOVE power and control, even if it's just an illusion.)

<comment><USER9> Egads, you're right. That is the sort of software you wouldn't use every day.

Personally, I find it surprising that customers would complain about you removing "trivial" options. Do you think you would lose customers (did they threaten to not use your product)? Would paying for your product change their opinion?

<comment><USER8> No, I don't think I'd actually lose anyone. It's hands-down the best tool for the job, and the only competition is from a product that I originally wrote as a freeware in cooperation with another site, was kicked off the project, and was subsequently turned into payware and has stagnated over the years. I could easily sell this product for 5 or 10 a pop and still have a decent userbase, but choose not to for not moral so much as karmic reasons.

But the thing about these features is.. they generate consumer goodwill. I don't know how else to explain it, but implementing stuff like this somehow makes geeks and grandmas alike more willing to endorse it. From the feedback that I've gotten, they feel it "speaks to them" and doesn't get in the way.

But what I've learned, regardless of the reason, keep your users happy and they'll recommend your product. They'll stick with you, and they'll _remember_ you.

Case in point: just yesterday, I added the final feature for the 2.0 milestone which is a blue border around the button used to select the current page when it has focus. Trivial feature. Except _instantly_ a user realizes that if they set an option to start EasyBCD up with a particular page, the blue border will remain along the default button. And they bug it, and when I say "it's really not worth fussing over" they insist: <http://neosmart.net/forums/showthread.php?t=6506>

That doesn't of course mean that I let the plethora of strongly-opinionated users take over the development of the software. I generally refuse most features. But the subtle enhancements they recommend, that's what I follow. Because it's just a bit more work for me, but it's makes the software go viral without even my trying.

One last thing: I'm absolutely against locking down features. I give users enough rope to hang themselves, but enough guiderails and warning messages that they don't do so blithely. And that opens the door to experimentation, to videos on YouTube where people use the software to do things I didn't think were possible and certainly never intended. And it keeps your users content with you, your software, and any future products you'll ever ship in the future.

tl;dr Features make EasyBCD's users happy. It's minor stuff, they would never abandon ship if it weren't there, but it makes them happy and it makes EasyBCD come to mind whenever someone needs a product that fits the bill.

</comment></comment></comment><comment><USER10> This article is little more than a generic rehash of popular memes. Let's break it down:

\- 37Signals is great, they do simple! \- anecdote \- Apple is great, they do simple!

I hope whatever software this guy does has less opinion and more substance.

<comment><USER11> Indeed, check out his dig at multitasking on Android and praise of iOS multitasking, even though Apple's implementation seems to be essentially identical.

<comment><USER12> It's not identical, Android lets you do a lot more in the background than iOS 4.0 does. That's the crux of my part about battery life... because it lets apps do anything in the background it will drain your battery. Apple didn't want to give developers that ability because they were concerned about regular users' iPhone batteries draining.

</comment></comment></comment><comment><USER13> I don't think it's black and white; you can have an opinionated, simplified front end, and a back end that is wide open. The back-end makes some things easier, such as testing, and helping admins deploy to 100+ users.

A flexible back-end can even be used to create an opinionated front-end. Consider a "factory defaults" file; preset any behavior, whether or not it has a checkbox. Try every combination, and convince yourself that one is better. Even with these decisions made up front, the interface is there to let other people disagree with you.

Mac OS X has a nice balance, because the built-in "defaults" command line program can tweak any setting that would also be available in the application's code. Just because a program is a GUI, doesn't mean that it should rely exclusively on GUI elements for configuration.

</comment><comment><USER14> At the farthest reaches of powerful software, you will always end up with a programming language and libraries.

At the other extreme, you have one thing that does exactly one task and as such can have a nearly "invisible" interface.

My suspicion is that it's actually kind of rare to need the areas in between - that apps like spreadsheets and photo editing are unusual, and if you _suspect_ that you have an app that could be developed in such a broad, deep, configurable way, your best bet is to start building in a library form and construct prototype one-shots - possibly even making them your MVP - <USER3> various different problems to see if you're right, before you try to make a unified monster UI for the perceived need.

</comment><comment><USER15> What if my opinion is that software should have _more_ settings? I am very opinionated about that.

<comment><USER16> Indeed, _all_ software is opinionated. You can't write anything remotely non- trivial without making decisions about what to do, where things go, what to add, what to leave out.

The key, though, is to do it willfully and deliberately. Realize that the end result will come with a point of view, and craft it on purpose.

</comment></comment><comment><USER17> Probably explains why Basecamp didn't click for us.

</comment><comment><USER18> To put that in a less confrontational way: instead of designing features, and then providing options to maximize your audience, first pick an audience, then make software that will work perfectly for them without the need for options. Result: a smaller, more dedicated audience, versus an audience of "everyone" and a product that is as well-suited to an individual task as Microsoft Office.

</comment><comment><USER19> I always cringe when I hear "don't listen to your customers." That is absolutely the wrong behavior. If you don't listen to the people who are going to buy your product, you won't build a product that solves a real problem.

I listen to my stakeholders (potential users, potential buyers, current users, etc), but I don't necessarily do what they say. Most people try to give you a solution to their problem, you need to dig through their "solution" to find their actual "problem", then design the best solution (and like all design, it is best not when nothing else can be added to it, but rather when nothing else can be taken away).

Oh, and I completely agree that software should be opinionated. People are paying you to solve their problem, don't get lazy and push responsibility back on them!

<comment><USER20> "don't listen to your customers" means doing exactly the way you describe it in the second paragraph. It does not mean "don't pay attention to what your customers are doing".

<comment><USER19> Except I've had conversations where people don't do that. I've also seen blogs that say "build what you want, if it's great it will sell." That is BS.

It is very similar to the "Fail Fast" mantra. Yes, if you apply it correctly, you will build a better startup. If you apply it naively, you will do just that: fail quickly.

"Don't listen to your customers" seems to resonate with engineers in a weird way. I think it is a combination of ego and anti-social behavior.

</comment></comment></comment><comment><USER21> Minor annoyance, but what's the bullshit sideshot against Android multitasking? Are we to believe now that only Apple get's multitasking right? "Apple invented multitasking"? It works fine on my N1. I think Steve didn't even say what makes multitasking on the iPhone so special.

That's how Apple marketing works, and frankly, it makes me dislike them despite of the neat design of their products. If their products are so great, why do they even need to work that kind of marketing?

</comment><comment><USER22> Apple doesn't listen to users and they're the most successful technology company in the world. They have a fearless leader who's not afraid to piss people off... Just like Zuckerberg.... Except we all complain about him. I suppose he needed the cult like following before you start to piss people off. That is the key.</comment>


Miami bridge collapsed as cables were being tightened following 'stress test' - <AUTHOR> https://www.usatoday.com/story/news/2018/03/16/authorities-miami-bridge-collapsed-cables-were-being-tightened-following-stress-test/431392002/ <comment><AUTHOR> I know this is still early in the investigation, but could anyone with relevant experience comment on whether this is normal? Running a 'stress test' on a new bridge without blocking traffic beneath it?</comment>


Software by Microsoft Is Nearly Free for the Needy - <AUTHOR> http://www.nytimes.com/2007/04/19/technology/19soft.html?ex=1334635200&en=73e2ccb3f118d36a&ei=5088&partner=rssnyt&emc=rss <comment><AUTHOR> The news came out after report that Microsoft sold only 244 copies of Vista in the whole of China in the first 2 weeks.</comment>


The conundrum of releasing Ubiquity 0.5 - <AUTHOR> http://www.azarask.in/blog/post/ubiquity-05-conondrum/

<comment><AUTHOR> Video summary: Both the 0.1.x and 0.5 branches will be maintained in parallel for a while, with 0.1 targeted at current users (to avoid breaking third-party commands) and 0.5 available for developers to port/write commands, and as an opt-in option for users. When enough commands and features are ready, 0.1 will go away and 0.5 will be pushed to all users.</comment>


The oldest recorded video, "Roundhay Garden Scene", England,1888 - <AUTHOR> https://youtu.be/Fxd8XJ_J0Gc <comment><USER2> I think we're only a few years of AI advances from being able to make this reconstruction color and 3D. Then being able to go look at the scene from other angles, or go into some of the doors and see inside the buildings.

Would it be true to reality? No. But it would be awesome nonetheless.</comment>


Top 350 HN Users - <AUTHOR> http://www.google.com/#sclient=psy&hl=en&site=&source=hp&q=site:news.ycombinator.com+3100...100000+inurl%3A%22%2Fuser%3Fid%22

<comment><USER2> For the top 100 see: <http://news.ycombinator.com/leaders>

From: <http://news.ycombinator.com/lists>

</comment><comment><USER3> Would be more useful if this could be sorted by average comment score.

I'd wager that most of the high karma HN users got there by submitting a lot of articles that got voted up.

<comment><USER4> I rarely submit. The mean of my comment scores also isn't very instructive, because I get +2..+4 on every non-angry comment solely due to name recognition.

<comment><USER5> I had to vote you up for that.

Apologies for the joke -- feel free to downvote. The meta was just too difficult to resist.

But seriously, he's right: after a certain point you start getting upvotes just -- because.

I'm not nowhere near as in the stratosphere as tptacek, but even I see it happen to my own comments from time to time. It was a lot more visible when everybody could see the comment scores.

</comment></comment></comment><comment><USER6> 3100 can't be the threshold for top 350 ... I'm almost on that and I'm a jerk.

</comment><comment><USER7> OT: does Google intentionally delay results after 10 pages? On the 10th page, it made me do a CAPTCHA to prove I was not a bot, and then every subsequent page took a couple seconds to load. It had been nearly instantaneous before that.

<comment><USER8> It might have something to do with the query looking a lot like a google dork (a search used to find vulnerable web apps)

</comment></comment><comment><USER9> When I try the link I get redirected to google.co.uk. Is this happening for anyone else?

<comment><USER10> I get redirected to google.ca and it frobs the parameters. Thanks, Google, once again for ruining things with your "region-specific" search experience.

</comment></comment><comment><USER11> I think the comment average to be a better measure. Some have high scores because they simply spend much too much time here :)

<comment><USER12> True, but some have higher average comment scores b/c they avoid making comments they expect will just earn 1 point, even if doing so would be beneficial to the discussion.

</comment></comment><comment><USER13> Clicking through the pages of this triggered google's captcha for me.

</comment><comment><USER14> I see only 183 in the results, not 350. Mine is not among them, though my karma is in the appropriate range and higher than some that are shown. Neat trick though.

</comment><comment><USER15> My karma is 1000 points low in Google's index. I wonder how that affects the "top 350" ranking.

</comment><comment><USER16> Unfortunately, this scoring of comments and karma preys on my OCD and competitive personality.

However, until I get psychological therapy from a certified professional, I kindly ask you vote me up. Thanks.</comment>


Foursquare & Groupon Hook Up for Real-Time Deals - <AUTHOR> http://mashable.com/2011/07/29/foursquare-groupon-partnership/ <comment><USER2> Smart for Foursquare and Groupon, not smart for businesses. This still doesn't fix the problem that Groupon is not a viable option for the majority of businesses.</comment>


Show HN: First Remote Jobs Board for Australia - <AUTHOR> https://goremote.com.au <comment><USER2> "pay what you want" feature is too risky, but quite interesting and affordable. Just curious - How do you think how many companies will pay more that $1?:)

<comment><AUTHOR> There are two main reasons we chose to launch with 'pay what you want' 1\. We wanted to to our little bit to help businesses during COVID

2\. Drum up interest during launch and make the barrier to posting a job as low as possible initially.

'Pay what you want me is not a long term pricing strategy. Likely we'll raise it to $99 in August and test higher prices until we find our sweet spot.

</comment></comment><comment><USER3> With this job board, can everyone from other part of world can work for Australian companies? or is it for Australians only?

<comment><AUTHOR> Initially, the job board will show all remote jobs that Australian's can apply for meaning the companies could be from anywhere. So the answer to your question is yes BUT it depends on the company and their specific requirements. For example there is a bunch of jobs live on the board right now that are open to anyone from anywhere. Hope that helps.

</comment></comment><comment><USER4> It's interesting that there hasn't been a remotes jobs board dedicated for Australia up until now!

<comment><AUTHOR> Kinda weird right. I guess it shows how little consideration there was for remote working in Australia pre COVID.

</comment></comment><comment><USER5> Oh, make it Australia and NZ please

<comment><AUTHOR> Hey, yes this is in our plans! Might fast track it now you have asked for it ;-)</comment></comment>


Ask HN: How much time do you spend selling? - <AUTHOR>

Hi HN'ers,
I was curious to know how much time your startups or businesses put into sales. This is mostly all you SaaS businesses or products that require active engagement with prospective customers (cold calls, emails, pitching).
How many hours a day do you put into this? What are your results like in terms of a days work: how many sales, how much $ revenue?
Thanks <comment><USER2> All of it. Business is selling.

<comment><AUTHOR> I take it your a sales person and only focus on sales? How many sales do you close per day? Whats the gross revenue of your work approximately?</comment></comment>


Automated Sports Content: The Future of Sports Journalism? - <AUTHOR> http://statsheet.com/blog/automated-sports-content-the-future-of-sports-journalism

<comment><USER2> Natural language generation is a fun topic. I'm currently building automated overviews of web stats at <http://overlytics.com>. Its a much smaller data domain to report over.

</comment><comment><USER3> This service just makes so much sense for both readers and the media outlets. Now every game in every sport can be summarized, plus it frees up time and resources that can be invested in expert analysis and other enhancements to the user experience.

The only thing I'd like to see is the ability to incorporate commentary from fans. ESPN and others already do live chats on various games and it seems like you could extrapolate meaningful events from that data if you had access to it.

</comment><comment><USER4> Will the automated content include interviews with players or quotes from coaches? You would need to scrape that content from non-automated sports stories.

<comment><USER5> Quotes are almost automated today. Most pro sports coaches and athletes endlessly recite the same cliches already.

<comment><USER6> The coaches just need to take it one game at a time.

</comment></comment></comment><comment><USER7> Holler when you get the hockey stats going! :)

<comment><AUTHOR> I'm getting the full NHL HITS feed now, so it's just a matter of time!</comment></comment>


TLS Everywhere, not https: URIs (2015) - <AUTHOR> https://www.w3.org/DesignIssues/Security-NotTheS.html <comment><USER2> Users/user agents need to know whether to _expect_ a connection to be secure. Unfortunately, you can't necessarily trust any random link you follow to reliably tell you. If I can get you to use HTTP when you should've used HTTPS, I might be able to sniff your traffic. If I can get you to use HTTPS when you should've used HTTP, it might be a DoS.

Incidentally, this is the same problem as public key distribution. You need a trusted channel to receive public keys, and a trusted channel to know whether to use a public key. Why can't these be the same channel? Right now we have HSTS preloading[1] for the latter, but in that case why not preload certificates (or hashes thereof) too?

Then we can finally cut out the middle-men and realize the truth: that the browser is the ultimate certificate authority.

[1] [https://hstspreload.appspot.com/](https://hstspreload.appspot.com/)

<comment><USER3> > Users/user agents need to know whether to expect a connection to be secure.

Why not expect it to be secure? Connect to https before http.

<comment><USER4> Behavior like that needs to come with a huge warning label.

It would be trivial for any man-in-the-middle to block https and server http.

<comment><USER5> This is exactly why browsers warn about such redirects. That said, this reminds me of a similar discussion on mail servers. There, STARTTLS sees much more use.

The main problem is preventing downgrade attacks. With mail it is easy to just remember the setting for every server. Not so with websites.

<comment><USER6> I've seen quite a bit of criticism of it for mail servers [1] because an attacker can simply block the 'STARTTLS' message and (many) clients will silently accept that.

[1] [https://www.agwa.name/blog/post/starttls_considered_harmful](https://www.agwa.name/blog/post/starttls_considered_harmful)

</comment></comment></comment></comment></comment><comment><USER7> _The problem is of course that moving things from http: space into https space, whether or not you keep the rest of the URI the same, breaks any links to. Put simply, the HTTPS Everywhere campaign taken at face value completely breaks the web._

Tim Berners-Lee is certainly an authority in the area, but I (an amateur) fail to see any major problem here, let alone one that "completely breaks the web".

Can someone illustrate a use case where either this fatal link-breaking cannot be solved by a simple HTTP->HTTPS redirect, or any other scenario where the user is so much worse off?

 _In a way it is arguably a greater threat to the integrity for the web than anything else in its history. The underlying speeds of connection of increased from 300bps to 300Gbps, IPv4 has being moved to IpV6, but none of this breaks the web of links in so doing._

I'd venture to say that IPv6 probably wishes it had the traction that HTTPS Everywhere has...

<comment><USER8> The URL that's supposed to redirect to HTTPS is still vulnerable to MitM. It can be modified in transit to serve up the same data as the HTTPS URL, but in plaintext, and potentially with a different form action attribute, etc. There are different things that can help with that, but none of them universally protect privacy.

<comment><USER7> That would mean HTTPS is not necessarily an improvement security-wise, but that does not explain how it "completely breaks the web" by "breaking links to".

To be more specific, I'm referring to the "Don't break the Web" section in the article.

</comment></comment></comment><comment><USER9> The problem with opportunistic TLS is that while it protects from wide-scale DPI it doesn't protect against MITM. Personally I think that the effort that would be put to implementing opportunistic TLS in all web servers and browsers would be better put to migrating all web applications to HTTPS only.

<comment><USER10> Agreed, and MitM is arguably a bigger threat than DPI to most people, especially if you use coffee shop wifi, etc.

</comment></comment><comment><USER11> It only breaks the web if you cut everything over from http to https. If you can serve both you don't have a problem.

This works fine if you use anchors without protocols in your html:

a href="//site.com/resource"

<comment><USER12> Some websites break if you try to access [https://](https://) \- from my experience of using Https Everywhere.

It's a simple fix to whitelist the one website though. It doesn't _break_ the Internet. It breaks sometimes, for some users, and is trivially fixable when it does break.

"Fundamentally breaking the internet", to me, is something that actually breaks the usability of the internet in a non-trivial-to-fix way for the end user where the end user isn't even in control of the fix. _That 's_ breaking the web.

Failing to support IE5 is "breaking the web" in the same way Https Everywhere breaks the web. In a way that is to be fixed on the user-end.

(Although sites that fail to serve over [https://](https://) should fix their site)

<comment><USER13> There's probably a technical reason I'm unaware of, but why are you allowed to have HTTP and HTTPS handled differently (besides then encryption portion)?

<comment><USER14> That's just how it happened. And historically, it was common to put only the "important things" behind TLS. That never really made sense from a security perspective, but it certainly saved CPU cycles.

<comment><USER15> I don't really like when I'm not able to read the news because HTTPS didn't want to collaborate with an unreliable connection.

</comment></comment></comment></comment></comment><comment><USER16> TBL's points here are well-made. In particular, there's the issue that security is a multidimensional probability field, not a binary state.

The questions of secure document transfer and/or interchanges are:

1\. Am I talking to the party I intended to?

2\. Is the communication free from third-party interception?

3\. Is the message itself originated by the party I intended?

4\. Are the _contents_ of that message as originally intended by the author?

(Possibly more, but those strike me as the Big Four.)

There are various ways for this to fail, and there are different _and independent_ assurances which can be afforded. I remeber the first time I heard phrases to the effect of "you can trust our secure webserver" in the context of commercial transactions, and cringed.

The present HTTP / HTTPS split addresses only a subset of these concerns, and few of them well, whilst breaking multiple elements of functionality.

I will note that TBL seems to be concerned over the expiration of old, previously-valid URLs. To that I can only say that this appears to be a lost battle. The duration of a contemporary URL is on the order of 40-45 days, I think from the Internet Archive. That's scarcely longer than an old-school Usenet post might be relied on to persist online, and suggests to me that perhaps the successor to Usenet _is_ the Web, with origins and various archival services (archive.org, archive.is, the NSA, ...) providing robust storage needs to various audiences.

</comment><comment><USER17> I find the HTTP/HTTPS "ring-fence" or "oil/water boundary", as he describes it, to be the most frustrating aspect of HTTPS, and recently wrote about it in some more detail (and how it might be fixed): [https://alexcbecker.net/blog.html#towards-universal-https- ad...](https://alexcbecker.net/blog.html#towards-universal-https-adoption)

</comment><comment><USER18> What exactly is he proposing? Without some additional change, if I make a link to [http://bank.com](http://bank.com), any MITM can trivially force an unencrypted connection and somehow the user needs to notice (or be lucky enough to have HSTS know about bank.com).

I can see an argument for having DANE-like records include an HSTS instruction, but nothing like that is mentioned in the article.

</comment><comment><AUTHOR> 5-10 years and [http://](http://) will be as rare as having a lottery jackpot. our kids kids will ask - what is this http? like our kids did with floppy disks...

<comment><USER19> I'm guessing in 10 years Chrome will refuse to connect to http hosts, given Google's track record of aggressively unilaterally deprecating and disabling web features they consider harmful.

</comment></comment><comment><USER20> if there was just one scheme for both and some kind of protocol upgrade needs to take place wouldn't it be easy to manipulate the connection and just doesn't let it take place?

</comment><comment><USER21> I used to think HTTPS everywhere was overkill, then I discovered HTTP2/ H2. H2 has some massive performance improvements and I believe we have barely scratched the surface of what is possible e.g. once the connection is established there's no need for additional HTTP handshakes, massively reducing latency.

I'm also a big fan of Let's encrypt, democratizing SSL certificates is only a good thing.

</comment><comment><USER22> Since most browsers now a days support SSL/TSL it's safe to redirect all traffic from http to the same url on httpS.

</comment><comment><USER23> Off topic, but I'm a native english speaker, and have never heard this construction before:

"There follow some thoughts following many recent discussions of "HTTPS Everywhere" and points west."

What does "and points west" mean here?

<comment><USER24> I _think_ you can interpret "and points west" as "and beyond."

I think it's based on the expression "all points west." Can't find a good source at the moment. "Points" is used as a plural noun there, not a verb. So, I think the expression "all points west" means "all locations to the west," and used metaphorically here to mean "all things beyond."

<comment><USER25> I have heard the phrase "points west" used when listing the places where a train is going. After listing the next several stops, they say "...and points west" to sum up all the stops the train will make that are too far away to be worth listing.

So I guess it's a metaphor for the indefinite beyond that makes sense to people who live on the east coast of the US and ever take the train.

</comment></comment></comment><comment><USER26> If we're designing in hindsight...

Browsers should connect to port 80 and perform a GET for /tls-cert with an Accept: header listing all the certificate formats it knows and the applicable Host: header.

The server would respond with the certificate for that host-name and the browser would validate it. After that, the HTTP connection would switch into TLS mode using the key in that certificate.

If the server responds to this initial request with 404 or some other error, the browser either shows an error or continues in insecure mode.

<comment><USER27> Delivering a TLS certificate over HTTP is useless as a MITM can simply substitute his own certificate.

<comment><USER26> Just like real-world TLS, the browser would validate the certificate before using it. TLS can be MITM'd too - if you can find a way around browser validation of the certificate.

</comment></comment></comment><comment><USER28> Looks like ppl didn't listen. I saw more https movement this days. and surely enough, it breaks...lots of stuff.

</comment><comment><USER29> as an ignorant user, I would just like to have a browser setting such as 'only talk to sites using TLS'. I would be happy to deal with the fallout. does chrome or other browser have that?

<comment><USER30> The EFF's 'HTTPS Everywhere' Firefox addon [1] has a setting to block all HTTP requests. This is not enabled by default [2], but when turned on, will exhibit the behavior you want.

[1] [https://addons.mozilla.org/en-US/firefox/addon/https- everywh...](https://addons.mozilla.org/en-US/firefox/addon/https-everywhere/)

[2] [https://www.eff.org/https-everywhere/faq#faq-When-does- HTTPS...](https://www.eff.org/https-everywhere/faq#faq-When-does-HTTPS- Everywhere-protect-me?-When-does-it-not-protect-me)?

<comment><USER29> thanks

</comment></comment></comment><comment><USER31> Just in case, note that it is _not_ against "TLS Everywhere", just against the separation of http: and https: schemes in the URI. TBL essentially argues that http: _should_ upgrade to TLS without any change in the URI (I think that this also implies that, when TLS deployment is finally universal, http: _should_ equal to today's https:).

<comment><USER32> If you set HTTP Strict Transport Security (which any site that believes it will continue to competently run SSL can and should do), it will implicitly upgrade all [http://](http://) URLs to [https://](https://), accomplishing the goal requested in this article without the security risks of optional/opportunistic encryption.

<comment><USER33> Only after you visit a domain.

<comment><USER30> Or if you preload with a browser vendor, which in all fairness doesn't scale in its current incarnation.

<comment><USER34> It's scaling well enough so far. A domain can be submitted at [https://hstspreload.appspot.com/](https://hstspreload.appspot.com/) and doesn't take long to show up in Chromium and then other browsers.

<comment><USER30> [a] If the ownership for the site's domain changes, how does the new owner undo the previous owner's preload?

[b] Is the only way to obtain the full preload list to extract it out of Chromium or Firefox source code? [1][2]

[1] [https://chromium.googlesource.com/chromium/src/+/master/net/...](https://chromium.googlesource.com/chromium/src/+/master/net/http/transport_security_state_static.json)

[2] [https://dxr.mozilla.org/comm- central/source/mozilla/security...](https://dxr.mozilla.org/comm- central/source/mozilla/security/manager/ssl/nsSTSPreloadList.inc)

<comment><USER35> The page linked above has instructions for removal.

<comment><USER30> Yes, the submission site talks about removal, and how it takes until the next major release of the browser for the changes to appear in the codebase, and every user will have to upgrade to pick up the changes.

If it were a HSTS preload registry service and API, that'd be different, but it's not.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER36> This is from early 2015. Should be noted in the title, since it more than 18 months old.</comment>


How to Construct 100% Bug-Free Software (Pay Attention, Toyota) - <AUTHOR> http://rebelscience.blogspot.com/2010/03/how-to-construct-100-bug-free-software.html

<comment><USER2> If I understand correctly this means we should just write small program that can learn which reactions to given stimuli of the program are good, and which aren't, based on history of signals and responses of the program that are known to be good.

While interesting, I doubt it will do much to make programs more correct.

Somebody has to tell the program that this new reaction is good, so you should learn it as an exception to the older rules, or it is wrong, and we have found a bug.

</comment><comment><USER3> I am starting to think this blog is an elaborate Markov-generated hoax.

That said, I've often wondered what Sokal is doing nowadays.

<comment><AUTHOR> You're wrong. There are serious people working, as I write, on implementing the author's vision.

<comment><USER3> "Mathematicians notwithstanding, a computer is a class of automaton known as a behaving machine. As such, it must not be seen as a function calculator that takes input arguments and returns an answer. It should be seen as belonging to the category of machines like brains and neural networks" from [http://rebelscience.blogspot.com/2010/02/computer- scientists...](http://rebelscience.blogspot.com/2010/02/computer-scientists- created-parallel.html)

I am sure there is meaning in this, but I am not sure it is a meaning that yields readily to rational thought. Hence my classification of the blog as noise.

<comment><AUTHOR> You are being disingenuous or purposefully obtuse since the author explains what he means in the same sentence. It's not rocket science.

<comment><USER3> <http://www.rebelscience.org/Crackpots/nasty.htm>

Do I need to spell out the similarities with Time Cube, or enumerate John Baez's Crackpot Index in an oddly self-referential strange loop?

It is indeed not rocket science. Or much of any science.

edit: "We are all accustomed to believe that everything is made of something. We are taught that matter consists of molecules and that molecules are made of atoms which are themselves made of even smaller components. This line of reasoning makes sense initially but, as seen below, it cannot be sustained." if you think I am merely being obtuse.

<comment><AUTHOR> You are worse than obtuse. You are plain dishonest. You are picking stuff up out of context in order to appear to make a valid disparaging point but you are just being an a*hole. And you know it.

<comment><USER4> Would you two please stop?

<comment><USER5> It's time for this I think: <http://news.ycombinator.com/item?id=1142045>.

Personal reprimands from you are effective in snapping otherwise reasonable people out of the mindset that sometimes results from anonymity, but it's just a stop-gap measure. I know you already know this, but it's worth pointing out.

Tangential anecdote: the last 10 or so uncivil comments I've read have been from throwaway accounts and accounts with small post counts/karma. I suspect most of these accounts are proxies for more active ones. Not sure if this metric can be leveraged in some way without producing too many false positives. Using machine learning to enforce civility is kind of ironic actually. Still, might be worth investigating.

<comment><USER4> I'm going to start trying things fairly soon. I'm just too busy with YC right now.</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Show HN: A rival to protobuf - <AUTHOR> https://github.com/compactr/compactr.js <comment><USER2> small piece of feedback on the presentation: "Schema based serialization made easy" is a lot better than "a rival to protobuf", especially if there are many ways in which it is _not_ a rival to protobuf

<comment><AUTHOR> Thanks for the advice, figured Protobuf would speak to a broader audience.

<comment><USER2> I think the other slogan is better because it mentions what you try to do _differently_ from protobuf, which is your selling point against protobuf (which has wider support, more language bindings, ... and thus is hard to compete with on the basis of just "we do the same")

</comment></comment></comment><comment><USER3> I'm missing some key entries here;

* Does it work on languages other than JS?

* How fast is it in comparison to PB? Only JSON is benchmarked and Compactr seems to be only minimally faster</comment>


Show HN: Ugly: A Universal Graphics Library - <AUTHOR> https://github.com/williamg/ugly

<comment><USER2> Can you really call anything running on node lightweight?</comment>


Short Rebol Examples: The simplicity and productivity of Rebol - <AUTHOR> http://re-bol.com/short_rebol_examples.r <comment><USER2> Here's a video which accompanies this post - [https://www.youtube.com/watch?v=lR5Fzv6DP0I&feature=youtu.be](https://www.youtube.com/watch?v=lR5Fzv6DP0I&feature=youtu.be)

</comment><comment><USER3> Also check out the successor to Rebol that's under development and seeking to be a "full-stack language," Red: [http://www.red-lang.org/](http://www.red- lang.org/)

<comment><USER4> I was certain I'd just looked at that page, but there appear to be a lot of new additions I can't recall. But does Red have I/O and network support now?

I suppose I should head over to gitter to ask, but perhaps someone here knows? I tried a search for http and network in the github repo, but didn't find anything that looked like support for slurping/pushing data over the network?

</comment></comment><comment><USER5> We'd a guy at my last job who really dug Rebol. It always looked very cool to me, like an even-better TCL, or almost-a-Lisp. I've never had time to dig into it, but I'd love to.

</comment><comment><USER6> Commented walkthrough of the examples: [http://learnrebol.com/rebol3_book.html#section-1.2](http://learnrebol.com/rebol3_book.html#section-1.2)

Apparently these code examples accompany the author's "book" on GUI Rebol programming.

</comment><comment><USER7> I wonder how many amazing programming technologies have been lost or neglected because they didn't draw pretty enough widgets on the screen.

</comment><comment><USER8> [http://www.rebol.com/oneliners.html](http://www.rebol.com/oneliners.html)

</comment><comment><USER9> Add repair services for the Samsung Galaxy necessary to replace the battery, the charge of alternative port [http://www.cellfixx.ca/](http://www.cellfixx.ca/)</comment>


Random($foo): Internet Asshattery, Armchair Scaling Experts Edition - <AUTHOR> http://www.randomfoo.net/blog/id/4171 <comment><USER2> He goes on a bit too long in this post, but I hope that the folks piling on to Blaine (who I don't know, but doubt is as incompetent as he's been made out to be) will read it. Scaling is not a simple problem, and many aspects of it are unique to the specific application. Given that Twitter runs on a not-very-fast framework built on a not-very-fast language and it rapidly became the largest site running that framework and language, one should really step back and ask, "is one IT guy going to be able to fix this?" and the answer is gonna probably be "no".

Premature optimization is the root of all evil, because it leads to micro- optimizations rather than architectural optimizations...since Twitter seems to be running an awful lot of boxes for shipping around tiny (really tiny) messages, I can't help but think they need some architectural optimizations. And that's something it takes the whole team to accomplish. One guy, particularly one guy without enough power to _make_ people fix their code, is going to be helpless in the face of that--he'll keep throwing hardware and edge caching (edge in the sense of at the edge of the outgoing network rather than the traditional sense of close to users--but without a lot of awareness of the data or application) at the problem. Sometimes it'll work, sometimes it won't.

I don't know Blaine or the Twitter situation, but I do know that scaling on a very large scale is never simple (my previous business was focused on web caching and scalability, and I've dealt with several quite large scaling situations--for sites burning way more bandwidth than Twitter). People outside of the situation probably shouldn't decide they know what went wrong and who was to blame.

<comment><USER3> The "premature optimization" advice is usually taken to mean "worry about performance later". But it can be very hard to make a system performant after the fact, when the important design decisions have long been made and a lot of code has been built on top of them.

I think what the advice really means is don't optimize _unnecessarily_. Figuring out what's necessary vs. what's frivolous optimization is actually a hard judgment call, so people (often good programmers who want to follow best practices) fall back on not optimizing at all, until they run smack into a brick wall. By then it can be too late.

I too know nothing about the Twitter situation, but it wouldn't be unusual if Blaine had nothing to do with the design decisions that are the root cause of their performance problems, nor if he had been asked to "make it scale" without actually having any power to affect the system in the necessary ways.

<comment><USER2> I didn't mean to rile the "optimization is more awesome than donuts" brigade. Really. I was just trying to say (unsuccessfully) that they're probably approaching the problem wrong, if one guy is expected to solve performance problems without giving him the power to make deep architectural changes. Let's pretend I never mentioned optimization, premature or otherwise.

You go right ahead and optimize early, often, and from both ends. I don't want to get in the way of a man and his passion for optimized code.

<comment><USER3> Oh, I wasn't disagreeing with you at all. I liked everything you said and thought I was just adding to it. In fact, I originally said something like "All this is by way of agreeing with everything you said" and then took it out because it seemed redundant!

<comment><USER2> I was merely pointing out the humor in the fact that whenever one says, "Premature optimization is the root of all evil", there will be a large number of people who spring to the defense of premature optimization. I wasn't picking on your post in particular...just the amusing fact that an off-the- cuff comment that didn't really express my intentions very well was the one sentence that got a very vocal response from several people, and yours was the first (and actually the post that signaled for the Premature Optimization Defense League).

It's a failing on my part for even bringing up premature optimization at all, particularly if I wanted to discuss anything other than premature optimization (or evil). I've been programming for over 20 years...I should have known what would happen.</comment></comment></comment></comment></comment>


Eat Me: The Food and Philosophy of Kenny Shopsin - <AUTHOR> http://www.amazon.com/gp/product/0307264939

<comment><AUTHOR> I urge you to listen to the podcast. The way he presents a 900-item menu and sizes up every client is really incredible.</comment>


Why People Check Their Phones at the Wrong Times and a Simple Trick to Stop It - <AUTHOR> http://www.nirandfar.com/2016/03/why-people-check-their-phones-at-the-wrong-times.html <comment><USER2> > Posing a direct question does the person a favor by pulling him back while > sending a clear message. The technique works like a charm. For one, the > unexpected question elicits an entertaining reaction — sort of like what > happens when you hold someone's nose when he's dozing off. He gasps and > sputters, but in this case it's not your fault, because you, as questioner, > can play dumb. "Oh, sorry, were you on your phone? Is everything O.K.?"

Despite how it's characterized in the previous paragraph, nothing about this technique is "subtle".

I really don't understand the impulse some people have to control the behavior of other adults.

</comment><comment><USER3> Social Antibodies regarding cell phone use is far more prevalent in Western (US) than in (most of) Asia for example. It is perfectly normal at all levels in business to take a phone call including movie theaters just to inform the caller that the recipient is in a movie theatre.

Japan on the other end has a culture of absolute mobile silence in the subway for example.

</comment><comment><USER4> About meetings. In two out of three companies I've worked for most of the meetings were basically pointless. That's the type of meeting where people would pull out their phone out of pure boredom. If you're having these kinds of meetings, it's not the screen behavior that is bad. It's just a symptom.

<comment><USER5> During boring meetings, I try to be deeply in the moment. I meditate. I Count my breaths.

This strategy has helped me leave boring meetings refreshed. Admittedly, there have been times where I've slipped up and reached for the screen.

</comment></comment><comment><USER6> Maybe when a social gathering starts you could just ask everyone if they would like to have a no-screens norm. People who want a screen ban would say why, and so would the ones who are opposed. I am thinking that this might work because someone who would want to take out their phone would be unhappy if someone else did, but feels like he or she can't stop it because it is an acceptable norm today. Maybe the person even realizes they have an addiction and would appreciate help fighting it. Maybe you could set a norm of only two minutes on the phone. Maybe people could think of other ideas. Maybe nothing would be decided on, but it would be an interesting discussion.

We could even have a web site where people would describe what happened. Speaking of which, are there any sites on overcoming web addiction?

</comment><comment><USER7> "This one weird trick to keep humans engaged".....

<comment><USER8> "This one weird trick to let you know I wrote a book"

</comment></comment><comment><USER9> If it bothers you and you are my friend, please just tell me, don't ask weird questions.

I won't be offended enough to speak up against it, you will have a slight benefit of doubt and I'll be in the defense, but I will recognize your manipulative, slightly dishonest behavior. (manipulative, because you want to trick me in to something and dishonest, because you cover your true intentions instead of stating what you really want.)

<comment><USER10> Why would you ask a weird question, instead of a normal question that relates to the current topic being discuss by the other member of the party?

</comment></comment><comment><USER11> I think the point about "phone stacking" is interesting. There doesn't need to be explicitly punitive measures to discourage people using their personal tech since the social conventions are already there.</comment>


Functions are data (and very cool data, too) - <AUTHOR> http://jaspervdj.be/posts/2009-12-23-functions-are-data.html

<comment><USER2> What's the problem that is actually trying to be solved? The user of your implementation will inform the design choices you make.

Using functions to represent objects like this is rather silly because they are opaque and only support a single operation.

Here are a number of possibly better ways to do it:

      - Emulate objects with functions and messages like with scheme or lisp.

      - Use structural typing or polymorphic variants like in OCaml.

      - Use records with function fields.

      - Use a variant union.

      - Extend/build a list monad over your class.

Can you think of other or better ways?

</comment><comment><USER3> The OO approach would be to have a virtual function in the parent class and then use lists of the parent class type. Does Haskell prevent that from working, or is he just attacking the OO approach based on a bad OO design?

<comment><USER4> I'd argue that he's using a bad FP approach. He focuses on one aspect of shapes: testing whether a point is inside it or not. But this is far from a complete, usable representation. How do you draw a shape? Find its edge? Find its bounds? Convex hull? Transform? Test for convexity?

Basically, the original post is just another newbie FP realising that - hey - if you're only every going to call one function of a class then the class is completely defined by that function. He presents a poor and incomplete solution.

There are much better blog posts on FP design than this. Please don't upvote this one.

</comment></comment><comment><USER5> Doe sql injection count?</comment>


Self-made Red Bull co-founder dies - <AUTHOR> http://www.cnn.com/2012/03/17/world/asia/thailand-red-bull-founder-dead/index.html <comment><USER2> All that Monopoly money now goes back into the box, for the next player.</comment>


Ask HN: Hey mobile devs, how often do you release to an app store? - <AUTHOR> At my company, our mobile teams have releases to their app stores about once a month. I am a backend developer and was wondering what this looks like for other mobile teams. A secondary question is if this release cycle includes Android and iOS or are the two platforms allowed to maintain different release cycles?<p>Thanks! <comment><USER2> I've worked at a company where we'd release every week and heavily leverage feature gates to hide features before they were ready for launch. And I've worked at a company that had no defined cadence - we'd release in big, well- defined chunks when features were fully baked and fully QA'd; no feature gates were needed on the client here.

There's value in both approaches, but I think I prefer the latter when the team size is small. Once you have multiple teams/priorities, the equation changes and it makes sense to have a more distributed, less segmented process. But initially it's great to have the predictability of well defined, packaged, well-QA'd releases. Results in a very high quality product and makes it really easy to debug/fix issues between releases.</comment>


The Single Biggest Factor Affecting a Startup's Success - <AUTHOR> https://capitalandgrowth.org/questions/164/if-you-were-to-pick-one-and-only-one-single-bigges.html <comment><USER2> This guy got it right: > I'd say opportunity is the most important. I often meet talented entrepreneurs who put an incredible amount of time and effort into solving problems that ultimately lack real market opportunity.

All other problems can be solved, coded or worked out. But, market opportunity is the only thing that can't be fixed. If no one wants what your selling, then no amount of talent or hard work will save you.</comment>