While I agree with the criticisms to this article– it uses the term gaslighting wrong and incorrectly blames individual bloggers, the gist/sentiment is correct– the JS world is a mess, lot of hype not enough substance. And the same hype keeps repeated every few years– either the community suffers from amnesia or there are lots of junior programmers learning $HOT_THING and then moving on to other things.
I’d say Node is, like, not messy at all. Due to Node being younger, its ecosystem developed and matured in an age where per-project isolated local dependencies were becoming the norm.
Python is arguably uniquely messy due to the invention of virtualenv. I’m not aware of any other language community where the default way to make isolated projects for ages was a thing that made a whole local prefix with symlinks to the interpreter and whatnot and a script you’d have to run to bring it into $PATH. Python’s closest cousin (in terms of 2000s web dev evolution anyway), Ruby, did it all correctly relatively early on — the Bundler experience is just like npm/cargo/stack/etc.
But forget virtualenv, the real messiness of Python packaging is the freaking layering. Distutils, setuptools, pip, virtualenv (or the new project-based managers) — it’s all there and which part is handled by which layer gets confusing quickly.
The thing that worries me is that I don’t think the core Python devs get it: the packaging situation is so bad that it very well may kill the language. It should be all hands on deck, this is the most important thing for us to fix. But I don’t see that happening at all, and instead there’s fiddling with esoterica like walrus and match…
So one interesting twist here is that many core devs work for big companies that use their own build and deployment systems for Python. (e.g. I worked with probably a dozen core Python devs at Google many years ago.) So they may not feel the issue on a daily basis. I certainly feel it more now that I do more open source, although I was aware of it back then whenever I had to install NumPy, etc.
From what I hear Jane St. is in a similar situation with OCaml and OPAM. They sponsor the open source package manager, but they don’t actually use it themselves! Because they use a monorepo like Google. monorepo means “no version constraint solving”, which simplifies the problem drastically (it’s an NP complete problem).
I also think the problem is more complicated than “core devs don’t get it”. It’s more like the solutions being very constrained by what happened in the past. For a long time the import system / algorithm itself was a very big wart and there was a huge effort to clean it up.
I will say that I think most of these problems were known before Python 3, and I wish there was a hard break then, but that was already 12-15 years ago at this point. And then people would have probably liked the 2->3 transition even less, etc.
So one interesting twist here is that many core devs work for big companies that use their own build and deployment systems for Python. (e.g. I worked with probably a dozen core Python devs at Google many years ago.) So they may not feel the issue on a daily basis. I certainly feel it more now that I do more open source, although I was aware of it back then whenever I had to install NumPy, etc.
This is definitely the case with my cloudy overlords, although I will say that this may be changing. I think some people are recognizing that there is wisdom in not rolling their own and allowing devs to leverage familiar interfaces for packaging.
I’ve been using Python professionally since 2010, I used to absolutely love it, and I’ve finally just reached the point where I no longer consider it an acceptable choice for a greenfield project of any scale, no exceptions. Someone will always come around to suggest that it’s open source, and you should fix what you don’t like, but it’s been my experience that the community culture has settled into a state that no project or ecosystem ever recovers from, which is when issues start being responded to with justifications along the lines of “this can’t change because of fundamental technical deficiency X, which because of its magnitude we’ve decided to stop treating as a technical deficiency in favor of treating it as a fundamental invariant of the universe, in spite of ample evidence that there are better ways to do it.” Either that technical deficiency is truly unsurmountable, in which case the tool is de jure broken and I have no good reason to use it, or that technical deficiency is surmountable but there will never be any will to fix it, in which case the tool is de facto broken and I have no good reason to use it. I feel deep sadness about this, but at this point there is too little that is exceptional about Python to justify putting effort into fixing what’s broken. No tool lasts forever, maybe we should just accept that it’s time to sunset this one.
Thats a great point, and a good answer to “Why don’t you just fix it yourself” that is thrown anytime you complain about any open source project, especially established ones like Python.
Python especially has this cultish mentality “All if perfect how dare you suggest otherwise”
The thing that worries me is that I don’t think the core Python devs get it: the packaging situation is so bad that it very well may kill the language. It should be all hands on deck, this is the most important thing for us to fix. But I don’t see that happening at all, and instead there’s fiddling with esoterica like walrus and match…
Python’s governance is pretty transparent. Do you have concrete suggestions for improvement? If you do, consider coming up with even a proof of concept implementation and creating a PEP.
the real messiness of Python packaging is the freaking layering. Distutils, setuptools, pip, virtualenv (or the new project-based managers) — it’s all there
Yup +100 to this … This is why I sometimes download tarballs with shell scripts and use “python setup.py build” instead. That’s only one layer :)
That approach doesn’t work all the time, e.g. if you have a big NumPy stack, or a big web framework with transitive dependencies.
On the other hand, if it works, then you know exactly what your dependencies are, and you can archive the tarballs somewhere for reproducible builds, etc.
the Bundler experience is just like npm/cargo/stack/etc
Thatk’s mostly splitting hairs, but for me there’s a big difference with cargo when it comes to experience: cargo run / cargo build just work, while bundle exec, npm run require running install command manually.
There’s a lot that node gets right simply by virtue of being a younger language and community than Python or Ruby by a long shot, so it could benefit from observing the effect of critical decisions over time.
Unfortunately that lack of maturity can express itself in various ways, some merely cosmetic, some less so.
Overall even as someone like myself who doesn’t love the language, having now learned it I can appreciate that there’s a lot of interesting work going into that community that bears watching and learning from, whatever your first choice in programming languages may be.
There is a tipping point in languages in near history ,sometime after Go I would say, where it got better but before that tipping point most language package managers have a large body of tech debt trying to deal with how muddy the line between global and localized package installs are. It affects Python, Perl, Ruby, PHP and a host of others.
that is IMHO the one true reason docker got popular. It said, screw it, we just package up the whole filesystem and run that in prod. Now that is the de-facto standard everywhere.
Oh undoubtedly. It made every language effectively a statically linked application for deployment purposes. Opinions are still divided on whether that was the best solution to this problem though. It’s definitely a solution and maybe the only one with a chance of succeeding.
Sometimes I fantasize about the idea of an alternative universe in which dynamic linking does is not used at all, everything is statically linked, and we dealt with the RAM and disk footprint by coming up with clever hacks for deduping code pages instead. :)
Dynamic linking solves the problem by introducing new problems that then spawned Docker which reintroduces the original problem again only it’s less of a problem now because disk and memory are “cheap”.
It’s why even though I know that Docker is solving real people’s real problems today, I simply can’t accept that this is the best we as an industry can do, or, rather, I don’t want to accept it, because it is such an indictment.
I totally agree, but I have left the “denial” phase behind and am now in the “acceptance” phase. I am running some self-hosted stuff and one is written in python. I am glad it is a docker container tbh, b/c setting that up on my server would be a mess.
I would love for some cleaner, purer solution to come along, but I fear that ship has sailed.
I also am free to be hyper arch about my technology choices because I no longer write software for a living and thus don’t continually run into disappointments, at least in my choices of tooling.
True– I’ve seen this problem with JS, Ruby and Haxe (and more languages, Im sure).
But I wrote about Python because:
It’s my main language
The problems have been around for years, and have become a joke now
Python is sold as a “beginners” language, but many beginners quit Python because they can’t even install the libraries
Edit: And to add, looking at some comments here, and on Reddit, there seems to be an attitude of “Lol, I’ve never seen this problem, you must be doing something silly/stupid” in the Python community, and I wanted to address this.
(And yes, I’m sure other communities have this problem too– just in my limited experience, the JS crowd are more open and honest about this)
I moved to Fastmail a year ago, and have been happy with it.
Everytime I get an email on gmail, I spend a few minutes updating the email in whatever service sent me.
The reason for not deleting is: There are emails you might only get once a year, like from the tax guys, MOT/TV license (here in the UK). You might have to react quickly, and sometimes its just easier to reply from gmail, and update the address later
Absolutely agree with this. I switched to Fastmail with my own domain something like 5 years ago and I still have my Gmail address. I have it set to forward to my “new” address, as well, so that I don’t even have to log in to Gmail. When I noticed that an email I care about originally came into my Gmail address I update it (or tell the person who sent it).
Great advice. I was going to say this, but was pleasantly surprised to find it was already the top response. I will add: Your old account is still attack surface for anything that’s linked to it. Don’t get lax on the security just because you no longer use it every day.
With gmail, if you delete your account, nobody else can ever register that username. This is a very important precaution since it prevents people from impersonating you. It is not necessarily the case with other email services. So, if you are applying this advice to migrate away from a mail service that isn’t gmail, look into whether it has that protection. If not, strongly consider never deleting the account.
Same that I did, I moved to protonmail and just check my gmail once in a blue moon at this point in case someone forgot I had updated it. I’ve had my gmail since the early invite-only beta days and it gets bombarded with spam and garbage almost constantly as well as a lot of people using my email address to sign up for things in the states that apparently don’t do email verification…
I also used to get emails addressed to someone working at NVidia, got a medical insurance claim form at one point I think, as well as an invite to a wedding…
I’ve been doing this, along with having Gmail forward all my email to my new account. I did that so I’d have copies of all my emails. I also did a dump and then import of all my previous emails too.
Honestly, it’s been fine. I’ve also unsubscribed from a lot of things and deleted a few accounts.
Most of the static site generators don’t seem to generate “sites”. They instead generate “blogs”, with the concept of posts and pages very deep-rooted in the implementation.
I mention because I recently came across statik which is a static site generator written in Python which really lets you generate sites. You get to define the “models” which you’d like your site to have (if you define Post and Page models, you have something like pelican). Imagine Django, but compile-time (for the lack of a better analogy).
I might write a blog (heh) post on this later, but I would definitely suggest checking it out if you’re interested in static sites.
The handful or so that I have worked with all support defining models, Sculpin and Tapestry (i’m the author) call them content types, Jigsaw calls them collections. All three can be used to generate a static site, but for convenience (and likely because the usual users are minimalist bloggers) they come “blog aware” which simply means they have a blog collection configured out of the box.
I have used all three and a few others such as metalsmith (which also supports collections via plugin) for the purpose of generating small static sites with a handful of pages for clients as well as reasonable sized multi author blogs.
TL;DR, yes some SSGs come shipped with blog content types (models) pre-configured but that doesn’t make them only good for generating blogs.
This is interesting. I wish it didn’t use YAML though.
For the website, I ended up making a custom generator, and focus on blogs in most generators was one of the biggest reasons, even though not the only one.
Most of the static site generators don’t seem to generate “sites”. They instead generate “blogs”, with the concept of > posts and pages very deep-rooted in the implementation.
Bravo for saying this. I’ve faced the same problem, with static generators forcing me to give an author / date setting for each page. This might make sense for blogs, but doesn’t for the simple site I want to build.
And most of them force you to do things a certain way; it is so painful, which is no wonder people just go back to Wordpress.
Certainly, WebAssembly is bringing a lot of good existing C/C++ code to the frontend. In a personal project, I’m using libogg, libopus and libspeexdsp. I find it really cool to be able to use these from the web! (I guess these particular libs lend themselves well, because they have little interaction with the OS, and are very portable.)
And then there’re also the big names in game development porting their engines, of course.
For myself, Python 3 is different enough from Python 2 that it is close enough to learning a new language, and if I’m going to invest that much in a new language, it isn’t going to be Python. It’s just not compelling enough. I use Python for things mostly because I learned it 15 years ago and it is everywhere, not because it’s any good.
Despite the length of the linked article, I disagree. The most commonly used 99% of the language (besides the print function) are identical. For most of my day-to-day usage the code I write runs simultaneously under Python3 and Python2 with no modification.
One particular point of pain I’ve experienced is that many of the collection operations return generators now rather than lists, so the following code is the opposite of what my brain wants to happen:
>>> if filter(lambda _ : False, [1, 2, 3]):
... print("hi")
... else:
... print("bye")
...
hi
I can write Python3 code, but I end up having a bunch of list constructor calls everywhere because I don’t know what returns an actual list and what doesn’t. IMO, Python 2 hit the sweet spot for the language. It was good enough to get stuff done but had a clear ceiling on how complicated of a problem you should solve with it. Python 3 is trying to push that ceiling up but it’s not adding anything that I think actually pushes the ceiling up and it is adding some complication I don’t really have any interest in dealing with.
Hmm, I’m not sure. The boolean value of a list is True if the list is non-empty and False if it is. So the boolean value of filter(condition, list) is True iff it returns a non-empty list iff at least one element of list satisfies condition. Or do you have something else in mind?
The code snippet I showed above removes every element from the list but still goes through the True path of the if, this is because filter does not return a list in Python3, unlike Python2, it returns a generator, which is always True.
As someone who works extensively with Python 2 & 3, the differences aren’t that great. At least nothing a 2 minute Google can’t fix.
At this stage, I see no reason to start a new project in Python 2. Py2 is only used for legacy projects (at work, where upgrading isn’t easy. For my personal projects, I’ve moved to Py3).
Depends on what you use it for. Especially if you’re making GTK based GUIs, python 3 and its gobject is extremely different from python 2 and its pygtk.
I didn’t intend the title to be clickbait-y so much as merely attention-grabbing (hence not 10 Things You Can Do To Hire Better or whatever) but I guess it’s a fuzzy line. I generally am only motivated enough to write a blog post about something when I get annoyed about it, so my titles are often pretty angry :-)
I think you’re confused about who the author is addressing. They’re talking to some other “you”, but not you, apy. I don’t think it’s worth getting upset about, though actually I agree and find such titles a distraction.
Fortunately there’s an easy solution (for authors). Refer to “we” instead of “you”. Readers can decide to count themselves in the group or not, but it’s not a forced decision.
I am not disagreeing with the sentiment that many can do better at tech interviews, I’m disagreeing with the idea that it applies to everyone. People need to realize that the world is not the little corner they experience.
People need to realize that the world is not the little corner they experience.
Indeed! For example, if I write an article and want other people to read it, I’m going to try and submit it to the popular news aggregators with a catchy title. Sometimes being pithy requires sacrificing some accuracy. Sometimes attracting attention means saying something stupid or slightly inflammatory.
Hey, maybe you don’t like mildly inflammatory generalized statements such as “you suck at {…},” but, on the same token, outside your corner of the world, plenty of folks understand that a title may have been chosen to catch someone’s attention and not be the cornerstone of precision.
Yes, and I expressed my opinion by downvoting and explaining by downvote and how I think the community can do better by steering contributors to having less inflammatory titles. Feel free to support such titles.
Note that similar posts successfully make it to websites such as here or reddit with less inflammatory titles quite often, so I don’t think your response is a sufficient justification.
Yes, and I expressed my opinion by downvoting and explaining by downvote and how I think the community can do better by steering contributors to having less inflammatory titles.
… by smugly proclaiming that people should realize that the world is not limited to their corner of experience. I’m just throwing it right back at ya. ;-)
Feel free to support such titles.
Oh I feel free. And I will.
Note that similar posts successfully make it to websites such as here or reddit with less inflammatory titles quite often, so I don’t think your response is a sufficient justification.
Please don’t twist my words. I didn’t come close to implying that one had to write inflammatory titles to get people to read them.
And I wasn’t trying to “justify” anything. I was merely pointing out that you should take your own advice: some people like to get creative with titles. Some people write titles to attract attention—not to be a bastion of precision. (As in, your overly literal interpretation of the title to actually mean the author was talking to people he didn’t know—like you—is ironically indicative that you are living in your own little world.)
I’ve been asked this question too, and I gave one answer (the same as in the blog). The interviewer then proceeded to give me 3 more ways you could solve the same problem, each more esoteric than the previous. It was clear he had Googled the answer before the interview because as the blog says, this isn’t really a problem you’d face in real life.
I think it depends on what you are doing it for: As a learning project, or something you want to charge money for (ie, something like a MVP)?
For a learning project, you do as much as you can. Because all abstractions leak, you need to know exactly how the system is working across all layers.
If you are building something you want to charge for, or something else you’d like to show to others, to boost your resume for example, then you always use the most stable existing solution.
My preference is for the latter, even for hobby projects. The problem is, as I wrote in my blog recently (http://pyskool.com/one-day-programmers-day-will-never-come/) , people choose projects that will take 20 years to complete, and then get bored after 20 days. They then give up and go to the next cool thing, get bored with that, move on etc , never finishing anything.
So my personal preference is to take the smallest thing, and actually finish it. Outsource everything not core to your product. Don’t spend 7 days getting an SSL cert and integrating Stripe, when you could just add a Payal or Gumroad button in 7 minutes.
But this is me coming from a bootstrapped/MVP angle, and it will be different for you based on your goals. Which is the second thing: You need to know what your goals are. Choose based on that.
I’ve only done a tiny bit of playing with Sinatra, but I’d say that it’s an apt comparison. From my vague recollection of Sinatra I’d say it’s slightly more micro than flask.
Would it be fair to say that Flask is roughly equivalent to Sinatra, only in Python instead of Ruby?
Yes.
Except that, while in the Ruby world, Rails is the number one (only?) choice, the Python world is more fragmented. I won’t say if this is a good or bad thing. I personally prefer Flask.
I bought the book when it came out. It is more useful for people who already know some Flask, as it teaches best practices (a bit like 2 scoops of Django).
This struck a chord with me. I’ve spent a large portion of my life pretending I’m going to build something amazing. It comes in waves. Get an idea, imagine how awesome I’ll be when I bring that idea to life, feel accomplished over work I’ve yet to do, weeks and a few feeble attempts later realize I’ll never make that awesome thing and start to feel terrible. Then I come up with another idea. Wash, rinse, repeat.
It’s not enough to have great ideas. You need to finish them too.
That’s why I always recommend people start with small things that they can finish in a week or two, a month at most. It is very satisfying to finish things, no matter how small, and gives you the strength to carry on through the hard times.
So in order to argue that Python 3 is bad and development should stop and shift back to Python 2, it is a necessary prerequisite to explain why an all-volunteer army should stop volunteering in the way that they want to volunteer and start volunteering in the way that you want them to volunteer.
This frames the argument in stupid and highly misleading terms. The “Python 3 is bad” argument is a cause-and-effect argument: if the Python developers keep Python 2 deprecated while it’s heavily used, then the community will split, and there’s a presumption that splitting the community is bad. Countering this requires either disproving the implication or asserting that splitting the community isn’t bad, and this section fails to even attempt to address either of these.
Of the top 200 3rd party libraries, 80% have Python 3 support at the time of this writing.
If 99% of the libraries I’m using have Python 3 support, I’m stuck with Python 2. Unless I have enough time and expertise to port the libraries I’m missing (and of course I don’t), it really needs to hit that magical 100% for this talking point to go away.
This is equally absurd. For example in March 2014 Python 3 downloads overtook Python 2 downloads by a healthy margin 54% vs 46%.
I have to ask: who downloads Python from Python? I literally never have, either at home or at work. Everybody I know gets it from alternate distribution channels. I think this statistic is misleading; for instance, Debian’s popularity contest puts the ratio of installs of 2 to 3 at about 4:1.
Regardless, if downloads of the old, deprecated version of your software only trail the new version by 15%, something is terribly terribly wrong with your migration plan.
[Rails] by the way, is not backwards compatible either
Python 3 would be much less of a big deal if Python broke compatibility in major ways with every minor version. (Of course, Python as a whole would likely also be much less of a big deal.) Comparing your problems to those of a terribly-run project and claiming victory is hardly a compelling argument.
And, of course, the entire article misses the actual giant elephant in the room: huge volumes (I would guess a significant majority) of all the Python code anywhere in the world is internal code for companies which will never be ported because there’s no business benefit whatsoever but which nevertheless must be maintained.
I mean, I get it; you really like Python 3 and you think the improvements were well worth making. I do too! (Well, I happen to think they did Unicode 100% wrong. But everything else was an improvement.) But in the process, they’ve broken it into two languages, and because of the incompatibility I have to use Python 2 at work. So now I’m forced to either use a deprecated language at home or use different languages at home and work; and Python 3 is the worst combination of not better enough and not different enough from Python 2, so I’m not likely to pick it.
Very good points. I’ll add: I find this whole “If you don’t like it, fork it” attitude very bad- it reeks of passive aggressiveness and responsibility dodging, and the reason so many people are turned off from open source projects (I know I am). We are adult members of a community- don’t ask us to “fork off” any time we say anything that displeases you!
This is not a tiny Sourceforge hello world project. Python is a major commercial tool. It is a key part of many companies infrastructure, so much so that they stand to lose millions if Python breaks. I don’t know about the rest of the world, but here in the UK, Python has become the default language in many engineering firms, replacing everything from TCL to Bash scripts to (shudder) C code. And this didn’t happen by chance. It took many years of work by Python enthusiasts, one company at a time.
I know most people who visit forums like this (& Reddit and HN) come from a web background. I don’t know how hard it is to just migrate your code for a web app. But out here in the engineering world, it’s next to impossible. Like @whbboyd says, there is zero business sense to do so. And this is the second problem: A group of hobbyists / cool kids gang is running the show. “Don’t like what we’re doing? Don’t play with us then.”
The original blog pointed out that this decision was breaking the community apart. And I’m not sure the tone of this blog helps at all. This is not something that’s going away.
But I think I’ve said enough. I’ll go fork myself now.
I don’t know enough about the ins-and-outs of Python’s development, but I can personally vouch for the frustration of developing in Python 3. Not because the language itself is a problem (in fact, I’ve had very few problems with Python 3 as a language), but because the third party libraries which are so prevalent in Python 2 and nowhere near as available in Python 3.
Perhaps forking Python 2 is the proper solution, but there is always an issue with forking something standardized, as XKCD puts so well.
As a user, my only concern is having something usable for professional work. For now, that language is still Python 2 for me. Anecdotally, I am not alone. Whatever solution is chosen, a solution to this issue must be found.
I share your experience. If I could just magically move to writing Python 3 code, I’d be a happy camper. But the migration is a major bummer if you’re a library author since you really need to support both Python 2 and 3 simultaneously.
A few years ago, this was really difficult, but if you have the ability to drop support for Python <=2.5 and Python 3.{0,1,2}, then your life gets a bit easier. Armin Ronacher describes a somewhat sane strategy for writing code that is compatible with both Python 2 and 3.
I’ve done it, so it’s possible. But boy, was it a pain! It utterly sapped the fun out of the task and has been a source of some bugs. There are so many subtle differences between the languages that there is definitely some cognitive overhead to writing the OP’s “Python X” subset.
Aside from that, as you mentioned, dependencies can be a problem too. Many of the major libraries have been ported (or are almost ported), but it’s still incredibly easy to come across a library that doesn’t support 3 yet.
It’s probably likely that folks here already know this, but something I’ve been doing for the past couple years in every Python script I write is just starting with this line:
from __future__ import absolute_import, division, print_function, unicode_literals
The big and famous libraries got ported fairly quickly, but you may have one library that someone took from Sourceforge and then left the company, leaving you to maintain the code. And you can’t migrate until you replace that one library. And as far as the boss is concerned, there is no financial sense in moving to 3.0 (and I agree with him somewhat). It’s always, “Yes, it’s a good thing to do. We’ll put it on the backlog, and come back to it when we have time.”
But you never get time, as there is always one more feature, one more bug to fix.
This, I think, is the biggest reason. There’s enormous boatloads of commercial Python in the world (I’d speculate that it could easily be the majority of Python code written) which is all in Python 2 and which will never get ported (because that’s expensive and yields no business benefit whatsoever) but which still must be supported.
I agree with this in general, though don’t know about the Wordpress comment. Installing Wordpress takes two minutes, and is faster than hand crafting HTML. Not to mention, it’s so easy to extend and add functionality. I would always choose Wordpress as a first choice, unless I had a good reason not to.
Now, I’ll admit it to anyone that I hate PHP with the passion of a thousand burning suns.
… every PHP code base I’ve seen is an absolute wreck, and I pity the soul of the one who has to maintain it. How could any real engineer use PHP?
Designers weren’t afraid to use it. For the first time ever, PHP let dumb people (you know, people who understand people) …
… until now the embedded device landscape has been ruled by bit-banging neckbeard overlords …
Now the author might be trying to use literary freedom to entertain the reader as embedded software development isn’t always the most captivating topic. And, it’s true, that for the Internet of Things to really succeed, it will need an almost frictionless entry point – something PHP is excellent at. But does the author need to do so with such negativity?
(meta: I want to downvote this article because there I feel it’s negativity out weighs any benefit, but that isn’t one of the listed reasons. On purpose? I’d guess so, as the truly awful stuff (outright racism/sexism/etc) would probably be immediately moderated.)
Agreed. Don’t know what the PHP bashing was all about.
I have worked in embedded systems for about 10 years now, and if someone asked me how to enter the field, I’d ask them to buy a Raspberri Pi and start playing with it. Or buy a Arduino. I have no idea what this Alljoyn thing does.
While I agree with the criticisms to this article– it uses the term gaslighting wrong and incorrectly blames individual bloggers, the gist/sentiment is correct– the JS world is a mess, lot of hype not enough substance. And the same hype keeps repeated every few years– either the community suffers from amnesia or there are lots of junior programmers learning $HOT_THING and then moving on to other things.
I’d say Node is, like, not messy at all. Due to Node being younger, its ecosystem developed and matured in an age where per-project isolated local dependencies were becoming the norm.
Python is arguably uniquely messy due to the invention of virtualenv. I’m not aware of any other language community where the default way to make isolated projects for ages was a thing that made a whole local prefix with symlinks to the interpreter and whatnot and a script you’d have to run to bring it into $PATH. Python’s closest cousin (in terms of 2000s web dev evolution anyway), Ruby, did it all correctly relatively early on — the Bundler experience is just like npm/cargo/stack/etc.
But forget virtualenv, the real messiness of Python packaging is the freaking layering. Distutils, setuptools, pip, virtualenv (or the new project-based managers) — it’s all there and which part is handled by which layer gets confusing quickly.
The thing that worries me is that I don’t think the core Python devs get it: the packaging situation is so bad that it very well may kill the language. It should be all hands on deck, this is the most important thing for us to fix. But I don’t see that happening at all, and instead there’s fiddling with esoterica like walrus and match…
So one interesting twist here is that many core devs work for big companies that use their own build and deployment systems for Python. (e.g. I worked with probably a dozen core Python devs at Google many years ago.) So they may not feel the issue on a daily basis. I certainly feel it more now that I do more open source, although I was aware of it back then whenever I had to install NumPy, etc.
From what I hear Jane St. is in a similar situation with OCaml and OPAM. They sponsor the open source package manager, but they don’t actually use it themselves! Because they use a monorepo like Google. monorepo means “no version constraint solving”, which simplifies the problem drastically (it’s an NP complete problem).
I also think the problem is more complicated than “core devs don’t get it”. It’s more like the solutions being very constrained by what happened in the past. For a long time the import system / algorithm itself was a very big wart and there was a huge effort to clean it up.
I will say that I think most of these problems were known before Python 3, and I wish there was a hard break then, but that was already 12-15 years ago at this point. And then people would have probably liked the 2->3 transition even less, etc.
This is definitely the case with my cloudy overlords, although I will say that this may be changing. I think some people are recognizing that there is wisdom in not rolling their own and allowing devs to leverage familiar interfaces for packaging.
For what it’s worth, this is the #1 reason I keep not trying Python. It’s just a huge headache and I can’t care enough about it.
I’ve been using Python professionally since 2010, I used to absolutely love it, and I’ve finally just reached the point where I no longer consider it an acceptable choice for a greenfield project of any scale, no exceptions. Someone will always come around to suggest that it’s open source, and you should fix what you don’t like, but it’s been my experience that the community culture has settled into a state that no project or ecosystem ever recovers from, which is when issues start being responded to with justifications along the lines of “this can’t change because of fundamental technical deficiency X, which because of its magnitude we’ve decided to stop treating as a technical deficiency in favor of treating it as a fundamental invariant of the universe, in spite of ample evidence that there are better ways to do it.” Either that technical deficiency is truly unsurmountable, in which case the tool is de jure broken and I have no good reason to use it, or that technical deficiency is surmountable but there will never be any will to fix it, in which case the tool is de facto broken and I have no good reason to use it. I feel deep sadness about this, but at this point there is too little that is exceptional about Python to justify putting effort into fixing what’s broken. No tool lasts forever, maybe we should just accept that it’s time to sunset this one.
Thats a great point, and a good answer to “Why don’t you just fix it yourself” that is thrown anytime you complain about any open source project, especially established ones like Python.
Python especially has this cultish mentality “All if perfect how dare you suggest otherwise”
Python’s governance is pretty transparent. Do you have concrete suggestions for improvement? If you do, consider coming up with even a proof of concept implementation and creating a PEP.
Be the change you want to see in the world :)
Yup +100 to this … This is why I sometimes download tarballs with shell scripts and use “python setup.py build” instead. That’s only one layer :)
That approach doesn’t work all the time, e.g. if you have a big NumPy stack, or a big web framework with transitive dependencies.
On the other hand, if it works, then you know exactly what your dependencies are, and you can archive the tarballs somewhere for reproducible builds, etc.
Thatk’s mostly splitting hairs, but for me there’s a big difference with cargo when it comes to experience:
cargo run/cargo buildjust work, whilebundle exec,npm runrequire runninginstallcommand manually.There’s a lot that node gets right simply by virtue of being a younger language and community than Python or Ruby by a long shot, so it could benefit from observing the effect of critical decisions over time.
Unfortunately that lack of maturity can express itself in various ways, some merely cosmetic, some less so.
Overall even as someone like myself who doesn’t love the language, having now learned it I can appreciate that there’s a lot of interesting work going into that community that bears watching and learning from, whatever your first choice in programming languages may be.
@shantnu_tiwari, Which of the multitude of environment managers listed do you recommend?
I would try to stick to standard virtualenv + pip, if you can.
Some libraries may not work, but if you try the other package managers, you end up going down a rabbit hole…
Packaging problems are not unique to Python.
There is a tipping point in languages in near history ,sometime after Go I would say, where it got better but before that tipping point most language package managers have a large body of tech debt trying to deal with how muddy the line between global and localized package installs are. It affects Python, Perl, Ruby, PHP and a host of others.
that is IMHO the one true reason docker got popular. It said, screw it, we just package up the whole filesystem and run that in prod. Now that is the de-facto standard everywhere.
Oh undoubtedly. It made every language effectively a statically linked application for deployment purposes. Opinions are still divided on whether that was the best solution to this problem though. It’s definitely a solution and maybe the only one with a chance of succeeding.
Sometimes I fantasize about the idea of an alternative universe in which dynamic linking does is not used at all, everything is statically linked, and we dealt with the RAM and disk footprint by coming up with clever hacks for deduping code pages instead. :)
Oh, like dynamic linking :)
Dynamic linking solves the problem by introducing new problems that then spawned Docker which reintroduces the original problem again only it’s less of a problem now because disk and memory are “cheap”.
I wrote clever.
It’s why even though I know that Docker is solving real people’s real problems today, I simply can’t accept that this is the best we as an industry can do, or, rather, I don’t want to accept it, because it is such an indictment.
I totally agree, but I have left the “denial” phase behind and am now in the “acceptance” phase. I am running some self-hosted stuff and one is written in python. I am glad it is a docker container tbh, b/c setting that up on my server would be a mess.
I would love for some cleaner, purer solution to come along, but I fear that ship has sailed.
I also am free to be hyper arch about my technology choices because I no longer write software for a living and thus don’t continually run into disappointments, at least in my choices of tooling.
True– I’ve seen this problem with JS, Ruby and Haxe (and more languages, Im sure).
But I wrote about Python because:
It’s my main language
The problems have been around for years, and have become a joke now
Python is sold as a “beginners” language, but many beginners quit Python because they can’t even install the libraries
Edit: And to add, looking at some comments here, and on Reddit, there seems to be an attitude of “Lol, I’ve never seen this problem, you must be doing something silly/stupid” in the Python community, and I wanted to address this. (And yes, I’m sure other communities have this problem too– just in my limited experience, the JS crowd are more open and honest about this)
I am not a beginner, but I have quit using Python for new projects because it’s not worth my time to figure out how to install the libraries.
I regularly walk away from Javascript projects for the same reason.
keep your existing email account
make a new email account with whatever service provider you want
sign up for new accounts with your new email
whenever you have to log in to an existing service with your current email, if you have time, switch it to your new email
repeat until in a couple years everything is eventually switched over to your new one
This. No need to delete your gmail account.
I moved to Fastmail a year ago, and have been happy with it.
Everytime I get an email on gmail, I spend a few minutes updating the email in whatever service sent me.
The reason for not deleting is: There are emails you might only get once a year, like from the tax guys, MOT/TV license (here in the UK). You might have to react quickly, and sometimes its just easier to reply from gmail, and update the address later
Not to mention missed opportunities with people that only know your Gmail account.
Absolutely agree with this. I switched to Fastmail with my own domain something like 5 years ago and I still have my Gmail address. I have it set to forward to my “new” address, as well, so that I don’t even have to log in to Gmail. When I noticed that an email I care about originally came into my Gmail address I update it (or tell the person who sent it).
This is exactly what I did, though in addition I forwarded by gmail to my new address.
One missed step: Set up forwarding rule from old account to new account.
Great advice. I was going to say this, but was pleasantly surprised to find it was already the top response. I will add: Your old account is still attack surface for anything that’s linked to it. Don’t get lax on the security just because you no longer use it every day.
With gmail, if you delete your account, nobody else can ever register that username. This is a very important precaution since it prevents people from impersonating you. It is not necessarily the case with other email services. So, if you are applying this advice to migrate away from a mail service that isn’t gmail, look into whether it has that protection. If not, strongly consider never deleting the account.
Excellent advice. I also used this opportunity to migrate to a password manager, and ensure that I have updated, unique passwords everywhere.
Same that I did, I moved to protonmail and just check my gmail once in a blue moon at this point in case someone forgot I had updated it. I’ve had my gmail since the early invite-only beta days and it gets bombarded with spam and garbage almost constantly as well as a lot of people using my email address to sign up for things in the states that apparently don’t do email verification…
I also used to get emails addressed to someone working at NVidia, got a medical insurance claim form at one point I think, as well as an invite to a wedding…
Did you go to the wedding?
No. But I did reply to the invite saying o wouldn’t be able to make it.
I’ve been doing this, along with having Gmail forward all my email to my new account. I did that so I’d have copies of all my emails. I also did a dump and then import of all my previous emails too.
Honestly, it’s been fine. I’ve also unsubscribed from a lot of things and deleted a few accounts.
Most of the static site generators don’t seem to generate “sites”. They instead generate “blogs”, with the concept of posts and pages very deep-rooted in the implementation.
I mention because I recently came across statik which is a static site generator written in Python which really lets you generate sites. You get to define the “models” which you’d like your site to have (if you define
PostandPagemodels, you have something like pelican). Imagine Django, but compile-time (for the lack of a better analogy).I might write a blog (heh) post on this later, but I would definitely suggest checking it out if you’re interested in static sites.
I maintain 3 websites, two with Jekyll (https://monix.io and https://typelevel.org/cats-effect/) and one with Middleman (https://alexn.org).
Both Jekyll and Middleman are perfectly capable for static websites. The blogging part is just a nice built-in feature.
I’ve been using Nikola (edit: for my landing page), because at the time it was the only one that had incremental builds. You have to follow their guide to reconfigure it for a non-blog setup: https://getnikola.com/creating-a-site-not-a-blog-with-nikola.html
VuePress has my interest now, especially once Netlify support is implemented.
Edit: I also have Sphinx instances: one as a public wiki and the other as a private notes repo.
The handful or so that I have worked with all support defining models, Sculpin and Tapestry (i’m the author) call them content types, Jigsaw calls them collections. All three can be used to generate a static site, but for convenience (and likely because the usual users are minimalist bloggers) they come “blog aware” which simply means they have a blog collection configured out of the box.
I have used all three and a few others such as metalsmith (which also supports collections via plugin) for the purpose of generating small static sites with a handful of pages for clients as well as reasonable sized multi author blogs.
TL;DR, yes some SSGs come shipped with blog content types (models) pre-configured but that doesn’t make them only good for generating blogs.
This is interesting. I wish it didn’t use YAML though.
For the website, I ended up making a custom generator, and focus on blogs in most generators was one of the biggest reasons, even though not the only one.
Bravo for saying this. I’ve faced the same problem, with static generators forcing me to give an author / date setting for each page. This might make sense for blogs, but doesn’t for the simple site I want to build.
And most of them force you to do things a certain way; it is so painful, which is no wonder people just go back to Wordpress.
Amy Hoy wrote a great article on this : https://stackingthebricks.com/how-blogs-broke-the-web/
Lots of C bashing going on here.
I’ll only comment that C is used today mainly in the embedded domain, a place where it is strong and growing (in terms of jobs etc).
Perhaps webassembly will bring it out to the frontend!
Certainly, WebAssembly is bringing a lot of good existing C/C++ code to the frontend. In a personal project, I’m using libogg, libopus and libspeexdsp. I find it really cool to be able to use these from the web! (I guess these particular libs lend themselves well, because they have little interaction with the OS, and are very portable.)
And then there’re also the big names in game development porting their engines, of course.
For myself, Python 3 is different enough from Python 2 that it is close enough to learning a new language, and if I’m going to invest that much in a new language, it isn’t going to be Python. It’s just not compelling enough. I use Python for things mostly because I learned it 15 years ago and it is everywhere, not because it’s any good.
Despite the length of the linked article, I disagree. The most commonly used 99% of the language (besides the print function) are identical. For most of my day-to-day usage the code I write runs simultaneously under Python3 and Python2 with no modification.
One particular point of pain I’ve experienced is that many of the collection operations return generators now rather than lists, so the following code is the opposite of what my brain wants to happen:
I can write Python3 code, but I end up having a bunch of
listconstructor calls everywhere because I don’t know what returns an actual list and what doesn’t. IMO, Python 2 hit the sweet spot for the language. It was good enough to get stuff done but had a clear ceiling on how complicated of a problem you should solve with it. Python 3 is trying to push that ceiling up but it’s not adding anything that I think actually pushes the ceiling up and it is adding some complication I don’t really have any interest in dealing with.That’s an interesting point. I think you could try developing a habit of using
anyorallin such cases, e.g.:(Assuming that
Falseis a shortcut for a filtering condition that returnsFalsefor all items of the list). Would it help in your case?That doesn’t really capture the same thing, in reality it’s something like:
Hmm, I’m not sure. The boolean value of a list is
Trueif the list is non-empty andFalseif it is. So the boolean value offilter(condition, list)isTrueiff it returns a non-empty list iff at least one element oflistsatisfiescondition. Or do you have something else in mind?The code snippet I showed above removes every element from the list but still goes through the
Truepath of the if, this is becausefilterdoes not return a list in Python3, unlike Python2, it returns a generator, which is alwaysTrue.EDIT:
The output in the repl is:
This is the correct answer.
As someone who works extensively with Python 2 & 3, the differences aren’t that great. At least nothing a 2 minute Google can’t fix.
At this stage, I see no reason to start a new project in Python 2. Py2 is only used for legacy projects (at work, where upgrading isn’t easy. For my personal projects, I’ve moved to Py3).
Depends on what you use it for. Especially if you’re making GTK based GUIs, python 3 and its gobject is extremely different from python 2 and its pygtk.
I downvoted this specifically because I don’t think inflammatory titles like this should be supported.
It’s tough because the content is excellent but the title is intended to be clickbait-y.
I’m not sure what the answer is; maybe liberal HN-esque renaming of article titles?
I didn’t intend the title to be clickbait-y so much as merely attention-grabbing (hence not 10 Things You Can Do To Hire Better or whatever) but I guess it’s a fuzzy line. I generally am only motivated enough to write a blog post about something when I get annoyed about it, so my titles are often pretty angry :-)
I think you’re confused about who the author is addressing. They’re talking to some other “you”, but not you, apy. I don’t think it’s worth getting upset about, though actually I agree and find such titles a distraction.
Fortunately there’s an easy solution (for authors). Refer to “we” instead of “you”. Readers can decide to count themselves in the group or not, but it’s not a forced decision.
Surely there are people that can do them well, but they appear to be rare, and everyone can improve to some degree even if they are better than most.
I am not disagreeing with the sentiment that many can do better at tech interviews, I’m disagreeing with the idea that it applies to everyone. People need to realize that the world is not the little corner they experience.
Indeed! For example, if I write an article and want other people to read it, I’m going to try and submit it to the popular news aggregators with a catchy title. Sometimes being pithy requires sacrificing some accuracy. Sometimes attracting attention means saying something stupid or slightly inflammatory.
Hey, maybe you don’t like mildly inflammatory generalized statements such as “you suck at {…},” but, on the same token, outside your corner of the world, plenty of folks understand that a title may have been chosen to catch someone’s attention and not be the cornerstone of precision.
Yes, and I expressed my opinion by downvoting and explaining by downvote and how I think the community can do better by steering contributors to having less inflammatory titles. Feel free to support such titles.
Note that similar posts successfully make it to websites such as here or reddit with less inflammatory titles quite often, so I don’t think your response is a sufficient justification.
… by smugly proclaiming that people should realize that the world is not limited to their corner of experience. I’m just throwing it right back at ya. ;-)
Oh I feel free. And I will.
Please don’t twist my words. I didn’t come close to implying that one had to write inflammatory titles to get people to read them.
And I wasn’t trying to “justify” anything. I was merely pointing out that you should take your own advice: some people like to get creative with titles. Some people write titles to attract attention—not to be a bastion of precision. (As in, your overly literal interpretation of the title to actually mean the author was talking to people he didn’t know—like you—is ironically indicative that you are living in your own little world.)
Well, I am happy to be invited to the part of the world where interviews go well. :)
It’s not inflammatory at all. It is a bit misleading.
A better title would have been “You suck at taking interviews, and here’s why.”
Except it’s not about interviewers sucking at taking interviews, it’s about the industry sucking at giving them effectively.
How does the author know if I suck at technical interviews or not?
I’ve been asked this question too, and I gave one answer (the same as in the blog). The interviewer then proceeded to give me 3 more ways you could solve the same problem, each more esoteric than the previous. It was clear he had Googled the answer before the interview because as the blog says, this isn’t really a problem you’d face in real life.
I didn’t get the job.
Why did I think this would be a blog on how Indian food helps you concentrate better? :)
I think it depends on what you are doing it for: As a learning project, or something you want to charge money for (ie, something like a MVP)?
For a learning project, you do as much as you can. Because all abstractions leak, you need to know exactly how the system is working across all layers.
If you are building something you want to charge for, or something else you’d like to show to others, to boost your resume for example, then you always use the most stable existing solution.
My preference is for the latter, even for hobby projects. The problem is, as I wrote in my blog recently (http://pyskool.com/one-day-programmers-day-will-never-come/) , people choose projects that will take 20 years to complete, and then get bored after 20 days. They then give up and go to the next cool thing, get bored with that, move on etc , never finishing anything.
So my personal preference is to take the smallest thing, and actually finish it. Outsource everything not core to your product. Don’t spend 7 days getting an SSL cert and integrating Stripe, when you could just add a Payal or Gumroad button in 7 minutes.
But this is me coming from a bootstrapped/MVP angle, and it will be different for you based on your goals. Which is the second thing: You need to know what your goals are. Choose based on that.
Would it be fair to say that Flask is roughly equivalent to Sinatra, only in Python instead of Ruby?
I’ve only done a tiny bit of playing with Sinatra, but I’d say that it’s an apt comparison. From my vague recollection of Sinatra I’d say it’s slightly more micro than flask.
What do you mean? What’s there so heavy about Flask?
Yes.
Except that, while in the Ruby world, Rails is the number one (only?) choice, the Python world is more fragmented. I won’t say if this is a good or bad thing. I personally prefer Flask.
I bought the book when it came out. It is more useful for people who already know some Flask, as it teaches best practices (a bit like 2 scoops of Django).
This struck a chord with me. I’ve spent a large portion of my life pretending I’m going to build something amazing. It comes in waves. Get an idea, imagine how awesome I’ll be when I bring that idea to life, feel accomplished over work I’ve yet to do, weeks and a few feeble attempts later realize I’ll never make that awesome thing and start to feel terrible. Then I come up with another idea. Wash, rinse, repeat.
That’s why I always recommend people start with small things that they can finish in a week or two, a month at most. It is very satisfying to finish things, no matter how small, and gives you the strength to carry on through the hard times.
There’s a bunch of problems with this article.
This frames the argument in stupid and highly misleading terms. The “Python 3 is bad” argument is a cause-and-effect argument: if the Python developers keep Python 2 deprecated while it’s heavily used, then the community will split, and there’s a presumption that splitting the community is bad. Countering this requires either disproving the implication or asserting that splitting the community isn’t bad, and this section fails to even attempt to address either of these.
If 99% of the libraries I’m using have Python 3 support, I’m stuck with Python 2. Unless I have enough time and expertise to port the libraries I’m missing (and of course I don’t), it really needs to hit that magical 100% for this talking point to go away.
I have to ask: who downloads Python from Python? I literally never have, either at home or at work. Everybody I know gets it from alternate distribution channels. I think this statistic is misleading; for instance, Debian’s popularity contest puts the ratio of installs of 2 to 3 at about 4:1.
Regardless, if downloads of the old, deprecated version of your software only trail the new version by 15%, something is terribly terribly wrong with your migration plan.
Python 3 would be much less of a big deal if Python broke compatibility in major ways with every minor version. (Of course, Python as a whole would likely also be much less of a big deal.) Comparing your problems to those of a terribly-run project and claiming victory is hardly a compelling argument.
And, of course, the entire article misses the actual giant elephant in the room: huge volumes (I would guess a significant majority) of all the Python code anywhere in the world is internal code for companies which will never be ported because there’s no business benefit whatsoever but which nevertheless must be maintained.
I mean, I get it; you really like Python 3 and you think the improvements were well worth making. I do too! (Well, I happen to think they did Unicode 100% wrong. But everything else was an improvement.) But in the process, they’ve broken it into two languages, and because of the incompatibility I have to use Python 2 at work. So now I’m forced to either use a deprecated language at home or use different languages at home and work; and Python 3 is the worst combination of not better enough and not different enough from Python 2, so I’m not likely to pick it.
Very good points. I’ll add: I find this whole “If you don’t like it, fork it” attitude very bad- it reeks of passive aggressiveness and responsibility dodging, and the reason so many people are turned off from open source projects (I know I am). We are adult members of a community- don’t ask us to “fork off” any time we say anything that displeases you!
This is not a tiny Sourceforge hello world project. Python is a major commercial tool. It is a key part of many companies infrastructure, so much so that they stand to lose millions if Python breaks. I don’t know about the rest of the world, but here in the UK, Python has become the default language in many engineering firms, replacing everything from TCL to Bash scripts to (shudder) C code. And this didn’t happen by chance. It took many years of work by Python enthusiasts, one company at a time.
I know most people who visit forums like this (& Reddit and HN) come from a web background. I don’t know how hard it is to just migrate your code for a web app. But out here in the engineering world, it’s next to impossible. Like @whbboyd says, there is zero business sense to do so. And this is the second problem: A group of hobbyists / cool kids gang is running the show. “Don’t like what we’re doing? Don’t play with us then.”
The original blog pointed out that this decision was breaking the community apart. And I’m not sure the tone of this blog helps at all. This is not something that’s going away.
But I think I’ve said enough. I’ll go fork myself now.
I don’t know enough about the ins-and-outs of Python’s development, but I can personally vouch for the frustration of developing in Python 3. Not because the language itself is a problem (in fact, I’ve had very few problems with Python 3 as a language), but because the third party libraries which are so prevalent in Python 2 and nowhere near as available in Python 3.
Perhaps forking Python 2 is the proper solution, but there is always an issue with forking something standardized, as XKCD puts so well.
As a user, my only concern is having something usable for professional work. For now, that language is still Python 2 for me. Anecdotally, I am not alone. Whatever solution is chosen, a solution to this issue must be found.
I share your experience. If I could just magically move to writing Python 3 code, I’d be a happy camper. But the migration is a major bummer if you’re a library author since you really need to support both Python 2 and 3 simultaneously.
A few years ago, this was really difficult, but if you have the ability to drop support for Python <=2.5 and Python 3.{0,1,2}, then your life gets a bit easier. Armin Ronacher describes a somewhat sane strategy for writing code that is compatible with both Python 2 and 3.
I’ve done it, so it’s possible. But boy, was it a pain! It utterly sapped the fun out of the task and has been a source of some bugs. There are so many subtle differences between the languages that there is definitely some cognitive overhead to writing the OP’s “Python X” subset.
Aside from that, as you mentioned, dependencies can be a problem too. Many of the major libraries have been ported (or are almost ported), but it’s still incredibly easy to come across a library that doesn’t support 3 yet.
It’s probably likely that folks here already know this, but something I’ve been doing for the past couple years in every Python script I write is just starting with this line:
(Explanation.)
It obviously won’t solve every
2->3problem, but it’s a nice defensive measure that will reduce future burden.Agree with everything you say.
The big and famous libraries got ported fairly quickly, but you may have one library that someone took from Sourceforge and then left the company, leaving you to maintain the code. And you can’t migrate until you replace that one library. And as far as the boss is concerned, there is no financial sense in moving to 3.0 (and I agree with him somewhat). It’s always, “Yes, it’s a good thing to do. We’ll put it on the backlog, and come back to it when we have time.”
But you never get time, as there is always one more feature, one more bug to fix.
This, I think, is the biggest reason. There’s enormous boatloads of commercial Python in the world (I’d speculate that it could easily be the majority of Python code written) which is all in Python 2 and which will never get ported (because that’s expensive and yields no business benefit whatsoever) but which still must be supported.
I agree with this in general, though don’t know about the Wordpress comment. Installing Wordpress takes two minutes, and is faster than hand crafting HTML. Not to mention, it’s so easy to extend and add functionality. I would always choose Wordpress as a first choice, unless I had a good reason not to.
Man, this article seems unnecessarily negative:
Now the author might be trying to use literary freedom to entertain the reader as embedded software development isn’t always the most captivating topic. And, it’s true, that for the Internet of Things to really succeed, it will need an almost frictionless entry point – something PHP is excellent at. But does the author need to do so with such negativity?
(meta: I want to downvote this article because there I feel it’s negativity out weighs any benefit, but that isn’t one of the listed reasons. On purpose? I’d guess so, as the truly awful stuff (outright racism/sexism/etc) would probably be immediately moderated.)
Agreed. Don’t know what the PHP bashing was all about.
I have worked in embedded systems for about 10 years now, and if someone asked me how to enter the field, I’d ask them to buy a Raspberri Pi and start playing with it. Or buy a Arduino. I have no idea what this Alljoyn thing does.