> Any device not allowing that is, simply put, not respecting the intelligence of the user.
This is kind of a silly absolutist opinion. Sure, you should have an option to have a completely open mobile OS... but to say that any OS with other priorities than complete “openness” is disrespectful is to throw literally every other consideration to the wind. I mean... really, what about security?
Ideologues tend to forget about reality, sometimes, it seems. Verified app stores, for example, are about providing security to the end user, not about disrespecting the end user.
I can’t help but feel like ideologically driven projects like often almost immediately discredit themselves with crap like this. Their software comes off as about making some statement, not providing something great, novel, and beneficial to people.
I think part of their reasoning is that if they publish the rulebook, then people will find ways to misuse the services in a roundabout way. It’s easier to find bugs in source material you can see, than that you cannot.
I don’t agree with this, but I think it’s most likely the reasoning.
I disagree. Applicant should have done more to understand the requirements for the task. That’s a massive part of software engineering, and you would be surprised how much time software engineers will spend solving the wrong problem. He didn’t understand that part of the problem included rolling a novel solution or restricted use of a database. Almost a daily problem for software engineers is extracting this information from customers or systems engineers.
> Good software engineering is about leveraging existing robust tools in a new way, not about re-inventing a wheel while making is square.
Use of external libraries or solutions is often very restrictive (if not banned) in my field. We can use existing internal or known verified solutions. Not everything is so black and white, and not all options are always on the table. They rarely ever are.
I don’t think really think “leveraging existing tools” is a defining part of software engineering... though it certainly is part of it. Software engineering is much more than just coming up with solutions.
Sounds like you’re over reading into what was essentially a two-point comment... there was no snarkiness in that comment at all - just a statement that rust is not really offering much benefit for this circumstance. Yeesh... projection
> Python is easy to get started with, but once a project grows to any meaningful size, I would rather have a compiler
boy do I have a continent full of python developers to introduce you to... “python - by any means necessary” is their motto.
But in all seriousness, there are a lot of people (where I work) who started with python and have been daily driving it for so long that any other language is too tedious to get started with. Even if it means writing unreadable, hacky python, python still wins out for them.
I suspect there are a lot of similar people in data science.
> like dealing with Python2 vs Python3, and generally having to run everything in the context of a virtual environment, and the fact that it doesn't seem to really have a single "right way" to deal with dependency management.
Not to mention, this problem seems to be getting worse, not better. People are moving off of python 2.7, which was kind of the de-facto LTS release of python... leaving (currently) no LTS version of python and no clear path for the community to establish a new LTS version that the community will still support — there are so many releases with so many breaking changes in python 3 within the last few years that there is seemingly no consensus and no way to compromise.
> It's amazing how many great tools there are available in Python, but it does sometimes seem like it's an under-powered tool which has been hacked to serve bigger problems than it was intended for.
This is becoming more and more clear with every release of python IMO. The language is evolving too quickly for it to be used on large developments, but it’s still being used for that.
We have an entire test framework and libraries for high performance embedded systems level testing which is written entirely in python. The amount of high speed operations (timing tests, measurements, etc) is very obviously overwhelming for the intention of the language and libraries, yet the company keeps pushing ahead with this stuff. In order to mitigate the issue, we are developing more high speed embedded systems to offload the work from the test framework and report measurements to the framework. I think it’s quickly becoming extremely expensive and will only become more expensive — the framework is extremely “pythonic” to the point of being unreadable, using a number of hacks to break through the python interpreter. Jobs much better allocated to readable C++ libraries are being implemented in unreadable python spaghetti code with no clear architecture - just quick-and-dirty whatever-it-takes python.
I love python but I think it’s a quick-and-dirty language for a reason. What python does well cannot be beat by other languages (for example, prototyping), but I think it is often misused, since people can get something up and running quickly and cleanly in python, but it eventually has diminishing (and even negative) returns.