Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!1 -
Code katas are by far the most cringe thing I've ever seen in the dev world. Second place goes to dan abramov, third goes to python's “zen of python” naïveté being baked into the fucking language itself and printed out when you write “import this”.
4 -
The Zen Of Ripping Off Airtable:
(patterned after The Zen Of Python. For all those shamelessly copying airtables basic functionality)
*Columns can be *reordered* for visual priority and ease of use.
* Rows are purely presentational, and mostly for grouping and formatting.
* Data cells are objects in their own right, so they can control their own rendering, and formatting.
* Columns (as objects) are where linkages and other column specific data are stored.
* Rows (as objects) are where row specific data (full-row formatting) are stored.
* Rows are views or references *into* columns which hold references to the actual data cells
* Tables are meant for managing and structuring *small* amounts of data (less than 10k rows) per table.
* Just as you might do "=A1:A5" to reference a cell range in google or excel, you might do "opt(table1:columnN)" in a column header to create a 'type' for the cells in that column.
* An enumeration is a table with a single column, useful for doing the equivalent of airtables options and tags. You will never be able to decide if it should be stored on a specific column, on a specific table for ease of reuse, or separately where it and its brothers will visually clutter your list of tables. Take a shot if you are here.
* Typing or linking a column should be accomplishable first through a command-driven type language, held in column headers and cells as text.
* Take a shot if you somehow ended up creating any of the following: an FSM, a custom regex parser, a new programming language.
* A good structuring system gives us options or tags (multiple select), selections (single select), and many other datatypes and should be first, programmatically available through a simple command-driven language like how commands are done in datacells in excel or google sheets.
* Columns are a means to organize data cells, and set constraints and formatting on an entire range.
* Row height, can be overridden by the settings of a cell. If a cell overrides the row and column render/graphics settings, then it must be drawn last--drawing over the default grid.
* The header of a column is itself a datacell.
* Columns have no order among themselves. Order is purely presentational, and stored on the table itself.
* The last statement is because this allows us to pluck individual columns out of tables for specialized views.
*Very* fast scrolling on large datasets, with row and cell height variability is complicated. Thinking about it makes me want to drink. You should drink too before you embark on implementing it.
* Wherever possible, don't use a database.
If you're thinking about using a database, see the previous koan.
* If you use a database, expect to pick and choose among column-oriented stores, and json, while factoring for platform support, api support, whether you want your front-end users to be forced to install and setup a full database,
and if not, what file-based .so or .dll database engine is out there that also supports video, audio, images, and custom types.
* For each time you ignore one of these nuggets of wisdom, take a shot, question your sanity, quit halfway, and then write another koan about what you learned.
* If you do not have liquor on hand, for each time you would take a shot, spank yourself on the ass. For those who think this is a reward, for each time you would spank yourself on the ass, instead *don't* spank yourself on the ass.
* Take a sip if you *definitely* wildly misused terms from OOP, MVP, and spreadsheets.5 -
Started out with python, while meaning to learn javascript.
I am now competent in python. Im still not sure how it happened.
Started python because I got tired with doing repetative calculations by hand. I think I had like a phobia of problem solving with nested loops. any time I thought a problem would require nesting, especially more than one nested loop, I would just avoid doing it, or end up doing it by hand.
Wrote so many goddamn loops though in the process of exploring graphs, doing things by hand seems like a nuisance. Thinking in loops has its own zen or something.
Now I just need to get over my fear of json-based CLI-enabled configuration-over-convention.1 -
Note to devs here. Please don't choose a framework for the hype at your work. Use it on your own time or company hackaton/learning time.
I'm looking at you angular.
Production ready doesn't mean sanity ready.
Now because some dev choose such technology for arbitrary reasons. (hype, latest acronym on CV). I spend more time debugging and understanding than I would if some simpler technology was chosen. Look at all the options then choose the simplest one that has and seems to have active maintenance. Zen of python is the best thing to happen in programming and I think everyone, even if you don't like Python should follow it. Save you and your colleagues brain time and ask for advice.
Also IMO react is probably third or second best option, higher if one requirement is to be react native. Angular is even lower because it's complexity is unforgivable when a dev has not enough front-end experience.8 -
"if compiler can infer this, there is no need to add "x ->" , simply use it" ..AAAGHH FUCK YOUUUUU KOTLIN!! what else should i fucking not write? why do't you take a number of my employee and ask his requirements, maybe add a ShoppingKartApp.kt in your compiler next time? it will be completely inferred when i write "Fuck you" in the gradle.
And fucking companies are promoting this! I wonder how those devs are living there
Person A knows only that lambda is
{name:Type,name:Type->code}, and thus writes a clean code.
Person B comes says "This shit suck", writes "{ acc, i -> acc + " " + i }" ,goes away
Person A : "wtf is this shit? why it works?"
Please for the love of god, follow some rules! My first language was python, i love its zen:
- Beautiful is better than ugly.
- Simple is better than complex.
- Readability counts.
- Special cases aren't special enough to break the rules.
- There should be one-- and preferably only one --obvious way to do it.
- If the implementation is hard to explain, it's a bad idea.
-...
I just wish it follows at least one thing from python's zen : "There should be one-- and preferably only one --obvious way to do it."3
Top Tags
Weekly Rant
View