What is MATLAB and what are its top alternatives?
Top Alternatives to MATLAB
- R Language
R provides a wide variety of statistical (linear and nonlinear modelling, classical statistical tests, time-series analysis, classification, clustering, ...) and graphical techniques, and is highly extensible. ...
- NumPy
Besides its obvious scientific uses, NumPy can also be used as an efficient multi-dimensional container of generic data. Arbitrary data-types can be defined. This allows NumPy to seamlessly and speedily integrate with a wide variety of databases. ...
- Octave
It is software featuring a high-level programming language, primarily intended for numerical computations. Octave helps in solving linear and nonlinear problems numerically, and for performing other numerical experiments using a language that is mostly compatible with MATLAB. ...
- Tableau
Tableau can help anyone see and understand their data. Connect to almost any database, drag and drop to create visualizations, and share with a click. ...
- Python
Python is a general purpose programming language created by Guido Van Rossum. Python is most praised for its elegant syntax and readable code, if you are just beginning your programming career python suits you best. ...
- Matplotlib
It is a Python 2D plotting library which produces publication quality figures in a variety of hardcopy formats and interactive environments across platforms. It can be used in Python scripts, the Python and IPython shells, the Jupyter notebook, web application servers, and four graphical user interface toolkits. ...
- JavaScript
JavaScript is most known as the scripting language for Web pages, but used in many non-browser environments as well such as node.js or Apache CouchDB. It is a prototype-based, multi-paradigm scripting language that is dynamic,and supports object-oriented, imperative, and functional programming styles. ...
- PHP
Fast, flexible and pragmatic, PHP powers everything from your blog to the most popular websites in the world. ...
MATLAB alternatives & related posts
- Data analysis82
- Graphics and data visualization61
- Free53
- Great community44
- Flexible statistical analysis toolkit37
- Access to powerful, cutting-edge analytics26
- Easy packages setup26
- Interactive18
- R Studio IDE12
- Hacky9
- Shiny apps7
- Shiny interactive plots6
- Preferred Medium5
- Automated data reports5
- Cutting-edge machine learning straight from researchers4
- Machine Learning2
- Graphical visualization2
- Very messy syntax6
- Tables must fit in RAM4
- Arrays indices start with 13
- Messy syntax for string concatenation2
- No push command for vectors/lists2
- Messy character encoding1
- Poor syntax for classes0
- Messy syntax for array/vector combination0
related R Language posts










The algorithms and data infrastructure at Stitch Fix is housed in #AWS. Data acquisition is split between events flowing through Kafka, and periodic snapshots of PostgreSQL DBs. We store data in an Amazon S3 based data warehouse. Apache Spark on Yarn is our tool of choice for data movement and #ETL. Because our storage layer (s3) is decoupled from our processing layer, we are able to scale our compute environment very elastically. We have several semi-permanent, autoscaling Yarn clusters running to serve our data processing needs. While the bulk of our compute infrastructure is dedicated to algorithmic processing, we also implemented Presto for adhoc queries and dashboards.
Beyond data movement and ETL, most #ML centric jobs (e.g. model training and execution) run in a similarly elastic environment as containers running Python and R code on Amazon EC2 Container Service clusters. The execution of batch jobs on top of ECS is managed by Flotilla, a service we built in house and open sourced (see https://github.com/stitchfix/flotilla-os).
At Stitch Fix, algorithmic integrations are pervasive across the business. We have dozens of data products actively integrated systems. That requires serving layer that is robust, agile, flexible, and allows for self-service. Models produced on Flotilla are packaged for deployment in production using Khan, another framework we've developed internally. Khan provides our data scientists the ability to quickly productionize those models they've developed with open source frameworks in Python 3 (e.g. PyTorch, sklearn), by automatically packaging them as Docker containers and deploying to Amazon ECS. This provides our data scientist a one-click method of getting from their algorithms to production. We then integrate those deployments into a service mesh, which allows us to A/B test various implementations in our product.
For more info:
- Our Algorithms Tour: https://algorithms-tour.stitchfix.com/
- Our blog: https://multithreaded.stitchfix.com/blog/
- Careers: https://multithreaded.stitchfix.com/careers/
#DataScience #DataStack #Data
I am currently trying to learn R Language for machine learning, I already have a good knowledge of Python. What resources would you recommend to learn from as a beginner in R?
- Great for data analysis8
- Faster than list2
related NumPy posts

















Server side
We decided to use Python for our backend because it is one of the industry standard languages for data analysis and machine learning. It also has a lot of support due to its large user base.
Web Server: We chose Flask because we want to keep our machine learning / data analysis and the web server in the same language. Flask is easy to use and we all have experience with it. Postman will be used for creating and testing APIs due to its convenience.
Machine Learning: We decided to go with PyTorch for machine learning since it is one of the most popular libraries. It is also known to have an easier learning curve than other popular libraries such as Tensorflow. This is important because our team lacks ML experience and learning the tool as fast as possible would increase productivity.
Data Analysis: Some common Python libraries will be used to analyze our data. These include NumPy, Pandas , and matplotlib. These tools combined will help us learn the properties and characteristics of our data. Jupyter notebook will be used to help organize the data analysis process, and improve the code readability.
Client side
UI: We decided to use React for the UI because it helps organize the data and variables of the application into components, making it very convenient to maintain our dashboard. Since React is one of the most popular front end frameworks right now, there will be a lot of support for it as well as a lot of potential new hires that are familiar with the framework. CSS 3 and HTML5 will be used for the basic styling and structure of the web app, as they are the most widely used front end languages.
State Management: We decided to use Redux to manage the state of the application since it works naturally to React. Our team also already has experience working with Redux which gave it a slight edge over the other state management libraries.
Data Visualization: We decided to use the React-based library Victory to visualize the data. They have very user friendly documentation on their official website which we find easy to learn from.
Cache
- Caching: We decided between Redis and memcached because they are two of the most popular open-source cache engines. We ultimately decided to use Redis to improve our web app performance mainly due to the extra functionalities it provides such as fine-tuning cache contents and durability.
Database
- Database: We decided to use a NoSQL database over a relational database because of its flexibility from not having a predefined schema. The user behavior analytics has to be flexible since the data we plan to store may change frequently. We decided on MongoDB because it is lightweight and we can easily host the database with MongoDB Atlas . Everyone on our team also has experience working with MongoDB.
Infrastructure
- Deployment: We decided to use Heroku over AWS, Azure, Google Cloud because it is free. Although there are advantages to the other cloud services, Heroku makes the most sense to our team because our primary goal is to build an MVP.
Other Tools
Communication Slack will be used as the primary source of communication. It provides all the features needed for basic discussions. In terms of more interactive meetings, Zoom will be used for its video calls and screen sharing capabilities.
Source Control The project will be stored on GitHub and all code changes will be done though pull requests. This will help us keep the codebase clean and make it easy to revert changes when we need to.
Should I continue learning Django or take this Spring opportunity? I have been coding in python for about 2 years. I am currently learning Django and I am enjoying it. I also have some knowledge of data science libraries (Pandas, NumPy, scikit-learn, PyTorch). I am currently enhancing my web development and software engineering skills and may shift later into data science since I came from a medical background. The issue is that I am offered now a very trustworthy 9 months program teaching Java/Spring. The graduates of this program work directly in well know tech companies. Although I have been planning to continue with my Python, the other opportunity makes me hesitant since it will put me to work in a specific roadmap with deadlines and mentors. I also found on glassdoor that Spring jobs are way more than Django. Should I apply for this program or continue my journey?
- Free7
- Easy3
- Small code1
- Not widely used in the industry1
related Octave posts
- Capable of visualising billions of rows6
- 31
- Intuitive and easy to learn1
- Responsive1
- Very expensive for small companies1
related Tableau posts
Looking for the best analytics software for a medium-large-sized firm. We currently use a Microsoft SQL Server database that is analyzed in Tableau desktop/published to Tableau online for users to access dashboards. Is it worth the cost savings/time to switch over to using SSRS or Power BI? Does anyone have experience migrating from Tableau to SSRS /or Power BI? Our other option is to consider using Tableau on-premises instead of online. Using custom SQL with over 3 million rows really decreases performances and results in processing times that greatly exceed our typical experience. Thanks.
Python
- Great libraries1.1K
- Readable code947
- Beautiful code835
- Rapid development780
- Large community682
- Open source426
- Elegant385
- Great community278
- Object oriented268
- Dynamic typing214
- Great standard library75
- Very fast56
- Functional programming51
- Scientific computing43
- Easy to learn43
- Great documentation33
- Matlab alternative26
- Productivity25
- Easy to read25
- Simple is better than complex21
- It's the way I think18
- Imperative17
- Very programmer and non-programmer friendly15
- Free15
- Machine learning support14
- Powerful14
- Powerfull language14
- Fast and simple13
- Scripting12
- Explicit is better than implicit9
- Unlimited power8
- Clear and easy and powerfull8
- Ease of development8
- Import antigravity7
- It's lean and fun to code6
- Print "life is short, use python"6
- I love snakes5
- Fast coding and good for competitions5
- There should be one-- and preferably only one --obvious5
- Python has great libraries for data processing5
- High Documented language5
- Although practicality beats purity5
- Flat is better than nested5
- Great for tooling5
- Readability counts4
- Rapid Prototyping4
- Lists, tuples, dictionaries3
- Socially engaged community3
- Now is better than never3
- Web scraping3
- Complex is better than complicated3
- Multiple Inheritence3
- Plotting3
- Beautiful is better than ugly3
- CG industry needs3
- Great for analytics3
- Easy to setup and run smooth2
- Generators2
- If the implementation is easy to explain, it may be a g2
- Special cases aren't special enough to break the rules2
- If the implementation is hard to explain, it's a bad id2
- Simple and easy to learn2
- Import this2
- Many types of collections2
- No cruft2
- Easy to learn and use2
- List comprehensions2
- Can understand easily who are new to programming1
- Because of Netflix1
- A-to-Z1
- Only one way to do it1
- It is Very easy , simple and will you be love programmi1
- Powerful language for AI1
- Flexible and easy1
- Better outcome1
- Batteries included1
- Pip install everything1
- Should START with this but not STICK with This1
- Good for hacking1
- Powerful0
- Still divided between python 2 and python 351
- Performance impact28
- Poor syntax for anonymous functions26
- GIL21
- Package management is a mess19
- Too imperative-oriented14
- Hard to understand12
- Dynamic typing12
- Very slow10
- Not everything is expression8
- Explicit self parameter in methods7
- Indentations matter a lot7
- Poor DSL capabilities6
- Incredibly slow6
- No anonymous functions6
- Requires C functions for dynamic modules6
- Hard to obfuscate5
- Threading5
- Fake object-oriented programming5
- The "lisp style" whitespaces5
- Official documentation is unclear.4
- Circular import4
- Lack of Syntax Sugar leads to "the pyramid of doom"4
- Not suitable for autocomplete4
- The benevolent-dictator-for-life quit4
- Meta classes2
- Training wheels (forced indentation)1
related Python posts











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
Winds 2.0 is an open source Podcast/RSS reader developed by Stream with a core goal to enable a wide range of developers to contribute.
We chose JavaScript because nearly every developer knows or can, at the very least, read JavaScript. With ES6 and Node.js v10.x.x, it’s become a very capable language. Async/Await is powerful and easy to use (Async/Await vs Promises). Babel allows us to experiment with next-generation JavaScript (features that are not in the official JavaScript spec yet). Yarn allows us to consistently install packages quickly (and is filled with tons of new tricks)
We’re using JavaScript for everything – both front and backend. Most of our team is experienced with Go and Python, so Node was not an obvious choice for this app.
Sure... there will be haters who refuse to acknowledge that there is anything remotely positive about JavaScript (there are even rants on Hacker News about Node.js); however, without writing completely in JavaScript, we would not have seen the results we did.
#FrameworksFullStack #Languages
- The standard Swiss Army Knife of plotting10
- Lots of code5
related Matplotlib posts
Hi - I am looking to develop an app accessed by a browser that will display interactive networks (including adding or deleting nodes, edges, labels (or changing labels) based on user input. Look to use Django at the backend. Also need to manage graph versions if one person makes a graph change while another person is looking at it. Mainly tree networks for starters anyway. I probably will use the Networkx package. Not sure what the pros and cons are using Bokeh vs Matplotlib. I would be grateful for any comments or suggestions. Thanks.
JavaScript
- Can be used on frontend/backend1.6K
- It's everywhere1.5K
- Lots of great frameworks1.2K
- Fast894
- Light weight741
- Flexible424
- You can't get a device today that doesn't run js391
- Non-blocking i/o286
- Ubiquitousness235
- Expressive190
- Extended functionality to web pages54
- Relatively easy language48
- Executed on the client side45
- Relatively fast to the end user29
- Pure Javascript24
- Functional programming20
- Async14
- Setup is easy11
- Its everywhere11
- Full-stack11
- Because I love functions10
- JavaScript is the New PHP9
- Like it or not, JS is part of the web standard9
- Can be used in backend, frontend and DB8
- Expansive community8
- Easy8
- Can be used both as frontend and backend as well7
- Most Popular Language in the World7
- For the good parts7
- Everyone use it7
- Easy to hire developers7
- No need to use PHP7
- Future Language of The Web7
- Powerful6
- Photoshop has 3 JS runtimes built in6
- Love-hate relationship6
- Evolution of C6
- Supports lambdas and closures6
- Agile, packages simple to use6
- Popularized Class-Less Architecture & Lambdas6
- Client side JS uses the visitors CPU to save Server Res5
- 1.6K Can be used on frontend/backend5
- Versitile5
- Hard not to use5
- Its fun and fast5
- It's fun5
- Nice5
- Easy to make something5
- Can be used on frontend/backend/Mobile/create PRO Ui5
- It let's me use Babel & Typescript5
- Everywhere4
- Client processing4
- Function expressions are useful for callbacks4
- Stockholm Syndrome4
- What to add4
- Clojurescript4
- Promise relationship4
- Scope manipulation4
- Only Programming language on browser3
- Because it is so simple and lightweight3
- Easy to understand0
- A constant moving target, too much churn22
- Horribly inconsistent20
- Javascript is the New PHP15
- No ability to monitor memory utilitization8
- Shows Zero output in case of ANY error7
- Can be ugly6
- Thinks strange results are better than errors6
- No GitHub3
- Slow2
related JavaScript posts
Oof. I have truly hated JavaScript for a long time. Like, for over twenty years now. Like, since the Clinton administration. It's always been a nightmare to deal with all of the aspects of that silly language.
But wowza, things have changed. Tooling is just way, way better. I'm primarily web-oriented, and using React and Apollo together the past few years really opened my eyes to building rich apps. And I deeply apologize for using the phrase rich apps; I don't think I've ever said such Enterprisey words before.
But yeah, things are different now. I still love Rails, and still use it for a lot of apps I build. But it's that silly rich apps phrase that's the problem. Users have way more comprehensive expectations than they did even five years ago, and the JS community does a good job at building tools and tech that tackle the problems of making heavy, complicated UI and frontend work.
Obviously there's a lot of things happening here, so just saying "JavaScript isn't terrible" might encompass a huge amount of libraries and frameworks. But if you're like me, yeah, give things another shot- I'm somehow not hating on JavaScript anymore and... gulp... I kinda love it.











How Uber developed the open source, end-to-end distributed tracing Jaeger , now a CNCF project:
Distributed tracing is quickly becoming a must-have component in the tools that organizations use to monitor their complex, microservice-based architectures. At Uber, our open source distributed tracing system Jaeger saw large-scale internal adoption throughout 2016, integrated into hundreds of microservices and now recording thousands of traces every second.
Here is the story of how we got here, from investigating off-the-shelf solutions like Zipkin, to why we switched from pull to push architecture, and how distributed tracing will continue to evolve:
https://eng.uber.com/distributed-tracing/
(GitHub Pages : https://www.jaegertracing.io/, GitHub: https://github.com/jaegertracing/jaeger)
Bindings/Operator: Python Java Node.js Go C++ Kubernetes JavaScript OpenShift C# Apache Spark
PHP
- Large community948
- Open source814
- Easy deployment763
- Great frameworks484
- The best glue on the web384
- Continual improvements234
- Good old web183
- Web foundation145
- Community packages134
- Tool support124
- Used by wordpress35
- Excellent documentation33
- Used by Facebook28
- Because of Symfony23
- Dynamic Language21
- Cheap hosting16
- Easy to learn15
- Awesome Language and easy to implement14
- Fast development14
- Very powerful web language14
- Composer12
- Flexibility, syntax, extensibility11
- Because of Laravel10
- Easiest deployment8
- Worst popularity quality ratio7
- Fastestest Time to Version 1.0 Deployments7
- Fast7
- Readable Code7
- Short development lead times7
- Faster then ever6
- Most of the web uses it6
- Open source and large community5
- Simple, flexible yet Scalable5
- Easy to learn, a big community, lot of frameworks4
- Has the best ecommerce(Magento,Prestashop,Opencart,etc)4
- Is like one zip of air4
- Open source and great framework4
- Large community, easy setup, easy deployment, framework4
- Easy to use and learn4
- Cheap to own4
- I have no choice :(4
- Great developer experience3
- Great flexibility. From fast prototyping to large apps2
- Interpreted at the run time2
- FFI2
- Safe the planet2
- Hard not to use2
- Used by STOMT2
- Fault tolerance2
- Walk away2
- Simplesaml1
- Secure1
- Secure0
- So easy to learn, good practices are hard to find20
- Inconsistent API16
- Fragmented community8
- Not secure5
- No routing system2
- Hard to debug1
- Old1
related PHP posts
When I joined NYT there was already broad dissatisfaction with the LAMP (Linux Apache HTTP Server MySQL PHP) Stack and the front end framework, in particular. So, I wasn't passing judgment on it. I mean, LAMP's fine, you can do good work in LAMP. It's a little dated at this point, but it's not ... I didn't want to rip it out for its own sake, but everyone else was like, "We don't like this, it's really inflexible." And I remember from being outside the company when that was called MIT FIVE when it had launched. And been observing it from the outside, and I was like, you guys took so long to do that and you did it so carefully, and yet you're not happy with your decisions. Why is that? That was more the impetus. If we're going to do this again, how are we going to do it in a way that we're gonna get a better result?
So we're moving quickly away from LAMP, I would say. So, right now, the new front end is React based and using Apollo. And we've been in a long, protracted, gradual rollout of the core experiences.
React is now talking to GraphQL as a primary API. There's a Node.js back end, to the front end, which is mainly for server-side rendering, as well.
Behind there, the main repository for the GraphQL server is a big table repository, that we call Bodega because it's a convenience store. And that reads off of a Kafka pipeline.
















Our whole Node.js backend stack consists of the following tools:
- Lerna as a tool for multi package and multi repository management
- npm as package manager
- NestJS as Node.js framework
- TypeScript as programming language
- ExpressJS as web server
- Swagger UI for visualizing and interacting with the API’s resources
- Postman as a tool for API development
- TypeORM as object relational mapping layer
- JSON Web Token for access token management
The main reason we have chosen Node.js over PHP is related to the following artifacts:
- Made for the web and widely in use: Node.js is a software platform for developing server-side network services. Well-known projects that rely on Node.js include the blogging software Ghost, the project management tool Trello and the operating system WebOS. Node.js requires the JavaScript runtime environment V8, which was specially developed by Google for the popular Chrome browser. This guarantees a very resource-saving architecture, which qualifies Node.js especially for the operation of a web server. Ryan Dahl, the developer of Node.js, released the first stable version on May 27, 2009. He developed Node.js out of dissatisfaction with the possibilities that JavaScript offered at the time. The basic functionality of Node.js has been mapped with JavaScript since the first version, which can be expanded with a large number of different modules. The current package managers (npm or Yarn) for Node.js know more than 1,000,000 of these modules.
- Fast server-side solutions: Node.js adopts the JavaScript "event-loop" to create non-blocking I/O applications that conveniently serve simultaneous events. With the standard available asynchronous processing within JavaScript/TypeScript, highly scalable, server-side solutions can be realized. The efficient use of the CPU and the RAM is maximized and more simultaneous requests can be processed than with conventional multi-thread servers.
- A language along the entire stack: Widely used frameworks such as React or AngularJS or Vue.js, which we prefer, are written in JavaScript/TypeScript. If Node.js is now used on the server side, you can use all the advantages of a uniform script language throughout the entire application development. The same language in the back- and frontend simplifies the maintenance of the application and also the coordination within the development team.
- Flexibility: Node.js sets very few strict dependencies, rules and guidelines and thus grants a high degree of flexibility in application development. There are no strict conventions so that the appropriate architecture, design structures, modules and features can be freely selected for the development.