Hacker News Reader

Comment by rationalthug | Hacker News Reader

You do realize that Python was not only built to appeal to "non-devs" as well ad devs but, does, in fact, enjoy some of its strongest support from them- scientists, engineers, statisticians, etc., who do not consider themselves to be good developers. And, man, they can develop some crappy code/systems in Python too.

I like Python too (as well as node,) but your characterization of node is over-broad and, imo, inaccurate.

View on HN

> You do realize that Python was not only built to appeal to "non-devs"

... as an alternative to C++ and Perl. And in that respect, it is a snap to pick up. It is pretty easy, not as easy as, say, Javascript, but still easy to pick up, I agree.

Node.js is cancer. We all use it, because of the momentum it has with designers instantly being able to declare themselves "full-stack devs", but make no mistake -- Node.js and npm are an abomination that we will look back on in ten years and shudder.

Python is way easier to understand than JavaScript IMHO.

So you're saying bower is cancer? Webpack is cancer? Babel is cancer ? JavaScript module system made popular by nodejs is cancer? I largely prefer Python as a language but Nodejs is the best thing that happened to web development in years/ever

No, they are (well developed) bandaids to help deal with the cancer of javascript!

Your comment was about nodejs not JavaScript. Also give es6 js a try. It looks and feels like coding in Python (almost).

Hurray, here we go again! Uhh no, JavaScript is just fine, baring:

* implicit conversions, which you can get rid of at compile time using TypeScript or Flow.

* lack of explicit ints and ints with more than 31 bits (JITs can give you SMIs, or 31 bit integers for things they can prove are always integer values)

And thats about it.

> implicit conversions, which you can get rid of at compile time using TypeScript or Flow.

Javascript is fine if you don't use Javascript.

> lack of explicit ints and ints with more than 31 bits

Javascript is fine, except where it's garbage.

I don't really have a problem with javascript. I just don't want to build anything of any real complexity with it.

What I'm saying is that JS actually has a small amount of quirks compared to other dynamic languages. Just think about PHP's named functions, which are always in the global scope. Except when they are in namespaces (oh hi another concept), and then its kinda weird because namespaces are relative. There are no first class named functions, but function expressions can be assigned to variables. Which must be prefixed with $. There are no real modules, or proper scope; JS in turn implements modules cleanly on top of closures with lexical scope and objects.

In ruby, blocks are like lambdas except when they are not, and you can pass a block explicitly or yield to the first block implicitly. But there are also lambdas, which are different. Modules are again uselessly global, and cannot be parameterised over other modules (without resorting to meta programming). Oh yeah they are also another syntactical and semantical concept. Why not just `Module.new`? And there are classes, with private variables, which are prefixed with @.

The above examples are just scratching the surface

So yeah, I'm tired of people claiming that JS has the same amount of quirks as PHP. Boo hoo, its so horrible: no large ints, and implicit conversions. Compared to that, Ruby, PHP or (god forbid) Perl < 6 are total disasters. Pre-ES6, JS had the greatest power-to-number-of-concepts ratio of all current mainstream dynamic languages (1). With just prototypes, closures and objects, it manages to provide features that other languages do not with a dozen of base concepts

(1) cheating a bit here, because you could argue that Lisp or Lua are mainstream enough.

So how exactly is a comparison of JS/PHP/Ruby relevant in a dicussion about a tool rewritten from JS to Python?

It debunks the mistaken popular belief that JS is somehow a significantly worse language.

Also, I can't help but wonder how this: http://docs.python-guide.org/en/latest/dev/virtualenvs/ is somehow better compared to npm...

ok, let me rephrase that:

"We rewrote this from JS to Python."

"Guys but JS is better than PHP and Ruby!"

Still cant see how is that relevant.

Conveniently skipped the cancer part:

"We rewrote this from JS to Python!"

"They did this because JS is so horrible, its cancer!"

"Uhh, actually, JS is not significantly worse. It does well when compared with typical mainstream dynamic languages"

I think its worth debunking this supposed "cancerness" of JavaScript and the importance of the cited-to-death superficial "wat" talk on implicit conversions, by providing some perspective on where JavaScript's quirkiness actually lies on the popular dynamic languages spectrum.

Maybe then we will be able to have an actual discussion on the pros and cons of the language choice (like runtime availability, and the fact that package managers don't know what the heck to do with node and npm's sandboxed-by-default modules), instead of the middlebrow "its all just JS insanity" dismissals

I'm not convinced it's that they aren't just more layers of cruft piled on top of a shoddy foundation. One of these days the whole thing is going to subside into the morass, and maybe we'll get to start over on top of WebAssembly or whatever comes after that.

It's like the castle in the Holy Grail:

  When I first came here, this was all swamp. Everyone said I was daft 
  to build a castle on a swamp, but I built in all the same, just to 
  show them. It sank into the swamp. So I built a second one. That 
  sank into the swamp. So I built a third. That burned down, fell 
  over, then sank into the swamp. But the fourth one stayed up. 
  And that's what you're going to get, Lad, the strongest castle in 
  all of England.

> So you're saying bower is cancer? Webpack is cancer? Babel is cancer ? JavaScript module system made popular by nodejs is cancer?

So I write a ton of JavaScript including plenty in node. But make no mistake bower, webpack, babel and npm are all crap. They're hacks. Bandaids to make ES6, the web and JavaScript modules packaging and installation work correctly. They all have their own issues, huge dependencies (I mean holy crap it took me several minutes to install Babel last time I did it all just so I can use slightly different syntax and deal with map files? ugh).

"as an alternative to C++ and Perl"

Do you have a citation for that? My understanding of the timeline and Guido's writings on the subject make it seem very unlikely that C++ or Perl had any significant impact on the decision to create Python or the design of Python. Python would very likely still exist in a world without C++ or Perl, as far as I can tell.

Python isn't even in the same lineage as either of those languages, though it shares a lot of features and patterns with Perl (as there has been some cross-pollination between the communities over the years). And, Python (started in 1989) is only a couple years newer than Perl (1987) and Perl was tiny enough to likely not really even be on Guido's radar at the time.

There may be a bunch of developers who think in terms of their own evolution as coders, and when they discovered various things, and your history may have Python coming well after Perl (I know I only started using Python professionally six or seven years after I first used Perl). But, I think you're overlaying your own perception onto events and it's distorting the actual history.

>> My understanding of the timeline and Guido's writings on the subject make it seem very unlikely that C++ or Perl had any significant impact on the decision to create Python or the design of Python.

Look at slide 4 of http://www.aleax.it/Python/ep03_meta.pdf:

>>> "Putting Metaclasses to Work", by Ira Forman and Scott Danforth (AddisonWesley 1998) / strong influence on Python 2.2 & later / based on IBM SOMobjects & C++

That's only one thing coming to mind :) (immediately followed by the quote: "In the past, the subject of metaclasses in Python has caused hairs to raise and even brains to explode (see, for example Metaclasses in Python 1.5). Fortunately, in Python 2.2, metaclasses are more accessible and less dangerous." by Guido at https://www.python.org/download/releases/2.2/descrintro/ -- referencing same C++ book(s), actually)

Didn't Guido post a tongue-in-cheek ad for Python to a/the Perl mailing list in Python's early days? I tried to find it now but no luck.

I don't remember it, but I wouldn't doubt it. Certainly, both Guido and Larry have made tongue-in-cheek comments about Perl and Python and the (good-natured) competition for mind share. And, features have been borrowed in both directions, and many developers have gone back and forth (I certainly have multiple times across a couple of decades).

From the wikipedia entry:

https://en.wikipedia.org/wiki/Python_(programming_language)#...

"Over six years ago, in December 1989, I was looking for a "hobby" programming project that would keep me occupied during the week around Christmas. My office ... would be closed, but I had a home computer, and not much else on my hands. I decided to write an interpreter for the new scripting language I had been thinking about lately: a descendant of ABC that would appeal to Unix/C hackers. I chose Python as a working title for the project, being in a slightly irreverent mood (and a big fan of Monty Python's Flying Circus)."

I'm surprised to see JS described as easier than Python. I'd say it's considerably harder and more complex. The first reason being that it forces you to think about asynchronosity constantly, and that's something a beginner's going to struggle with -- not just the idea that your code won't run in order, but that there are so many ways to deal with it (callbacks, promises, async/await, event emitters) all with their own tradeoffs. The second being that the standard library is anemic, so a ton of what you'd just hit the Python Stdlib for you have to either write yourself or sift through npm to find. Then there's the wildly varying code styles: this person/book encourages the traditional imperative style using loops and mutations, this other person encourages a functional style using folds and maps to do the same things. Prototype-based inheritance is less intuitive than class-based inheritance. There are multiple ways to do everything, even things as simple as variable assignment (var, let, const, implicit global, function foo() vs let foo = function() vs const foo = () =>), weird invisible things that trip you up like hoisting and how creating a global variable looks exactly the same as reassigning an existing local variable. New users will inevitably encounter the multiple competing module systems and either confuse syntax or fret about which to use.

I agree that it's cancerous, and that making the server side more accessible to front-end developers isn't worth all the problems Node introduces long-term. My dream is still a statically-typed version of Erlang.

You are absolutely correct. JavaScript is by no means as easy for a beginner than Python. Once you get beyond the most basic of programs , JavaScript starts throwing a lot of crazy concepts at you like prototypical inheritance,hoisting, and this (and I'm only counting es5)

The most intimidating part of Js isn't even the language, it's the ecosystem.

When you bundle it with HTML/CSS it's an easier start to GUI development then python.

I agree completely, but doubt I could have put it as eloquently as you did.

I personally have found my go-to tool for web development - Scala. It is a breeze to work with, and I advise anyone looking to develop web apps to give it a try, especially if you're tired of dynamic languages

Agree Python is easier to learn than JS (at least the basics) but IMO JS has a much nicer environment(the browser) for teaching programming.

Reminds me of these post: http://prog21.dadgum.com/203.html

> My dream is still a statically-typed version of Erlang.

Your (our) dream is about to come true: https://github.com/j14159/mlfe

> weird invisible things that trip you up like hoisting

Huh? How can you get tripped up by hoisting? I'm genuinely curious.

Any time you have a closure that captures the hoisted variable. Most often, this happens with loops. Say, someone might start with this:

  for (var i = 0; i < 100; ++i) {
    foo().then(function() { bar(i); });
  }

Then when they realize why this doesn't work, try something like:

  for (var i = 0; i < 100; ++i) {
    var j = i; // this is inside the block, so it's scoped to it, right?
    foo().then(function() { bar(j); });
  }

And then that breaks too, and it's not at all clear why.

It's not that other languages don't have similar limitations - Python also doesn't have block-local variables, for example. The problem with JS is that is uses syntax that strongly implies that it does have block scope, but then quietly makes it do something unexpected when you try.

Ironically, the only other language that I know of that has the same exact problem is VB (pre-.NET one) - its "Dim" statement can similarly be used anywhere inside a function, including inside loops and other block constructs, but the scope is always the entire function.

Ok, thanks. I would call that a problem with not having block scope, not a problem with hoisting. Not trying to be pedantic; I was just confused about how hoisting could be such a problem. A language could have variable/function declarations hoisted to the top of block scope rather than the top of function scope.

And as I'm sure you know, JS now supports block scoped variables through `let` and `const`.

> My dream is still a statically-typed version of Erlang

So something like Haskell?

http://learnyouahaskell.com/introduction#so-whats-haskell

Don't confuse Node with Javascript. Node and the browser are where all the async behavior comes from, not JS. Specifically; if you've ever done any backend coding in Meteor, there is practically no async behavior at all.

But I do agree: Sometimes I see people try to push Node/Express as a good choice for teaching basic APIs. Its not the worst choice, but its startling how easy it is to forget how insanely confusing async callbacks are for new devs.

If you're not a .NET developer, what are you realistically going to use that hasn't already been dated? Rails? Django? Perl? PHP?

Can't answer for webdev, but for anything else, python and c++ with some mature library packs (boost, qt, eigen, scipy etc). They are not 'dated' in that tey don't have any expiration date. As N.Taleb points out in Antifragile, the best predictor of an idea's remaining lifetime is its current lifetime.

I like to think of C++ and Python as of concrete and wood: if you are to build houses, you better know concrete and wood. There are more fancy materials and prefab assembly, true, but these are better left for quick and dirty work for now, and used by people who already know concrete and wood.

It's sad Object Pascal has died, it was a good language with good history. C# has some of its legacy, I'd use it more but last time I checked, Mono still has severe performance problems.

Phoenix?

"x is cancer" is cancer. These sorts of hyperbolic generalizations lower the level of discourse. You haven't actually given any reason for your opinion.

Python is outstanding for nearly every purpose I've thrown at it, and I was a strong Java developer. Now if anyone asks me if they should learn R/Matlab/Java/C, I say "Sure, but learn Python first."

Which Python? We have two of them now.

Python 3 for all intents and purposes, unless you're in a field where Python 2 is still prolific (but if you are, then you probably already know that).

I've recently completed a project of moderate complexity. I began development on Python 3 in a Jessie vm, and later ported to and deployed on Python 2.6 on CentOS 6.

The process was not without its challenges, but developing on a modern platform and backporting was a breeze, and I'm not worried about upgrades.

Python was built to be simple, yes. But it was built by people who understood that simplicity means things like "explicit is better than implicit" and "there should be one - and preferably only one - obvious way to do it". So it's a language that takes an inexperienced coder, and makes things easy for them, while also gently guiding them towards the safer (if possibly longer) path.

This is in stark opposition to "just let me quickly do stuff, and I don't care if the resulting code is buggy and unreadable" - the VB6/PHP school of language and framework design. Which, unfortunately, seems to be a rather popular approach in the JS ecosystem, as well.

Non SE programming is often very naive, so many long sequences of statements.

Reply on news.ycombinator.com