As someone who spends time programming, I of course find myself in conversations with people who aren’t as familiar with it. It doesn’t happen all the time, but these discussions can lead to people coming up with some pretty wild misconceptions about what programming is and what programmers do.
- I’m sure many of you have had similar experiences. So, I thought it would be interesting to ask.
A lot people compleatly overrate the amount of math required. Like its probably a week since I used a aritmetic operator.
At the same time, I find it amazing how many programmers never make the cognitive jump from the “playing with legos” mental model to “software is math”.
They’re both useful, but to never understand the latter is a bit worrying. It’s not about using math, it’s about thinking about code and data in terms of mapping arbitrary data domains. It’s a much more powerful abstraction than the legos and enables you to do a lot more with it.
For anybody who finds themselves in this situation I recommend an absolute classic: Defmacro’s “The nature of Lisp”. You don’t have to make it through the whole thing and you don’t have to know Lisp, hopefully it will click before the end.
Removed by mod
??
Function/class/variables are bricks, you stack those bricks together and you are a programmer.
I just hired a team to work on a bunch of Power platform stuff, and this “low/no-code” SaaS platform paradigm has made the mentality almost literal.
I think I misunderstood lemmyvore a bit, reading some criticism into the Lego metaphor that might not be there.
To me, “playing with bricks” is exactly how I want a lot of my coding to look. It means you can design and implement the bricks, connectors and overall architecture, and end up with something that makes sense. If running with the metaphor, that ain’t bad, in a world full of random bullshit cobbled together with broken bricks, chewing gum and exposed electrical wire.
If the whole set is wonky, or people start eating the bricks instead, I suppose there’s bigger worries.
(Definitely agree on “low code” being one of those worries, though - turns into “please, Jesus Christ, just let me write the actual code instead” remarkably often. I’m a BizTalk survivor and I’m not even sure that was the worst.
My take was that they’re talking more about a script kiddy mindset?
I love designing good software architecture, and like you said, my object diagrams should be simple and clear to implement, and work as long as they’re implemented correctly.
But you still need knowledge of what’s going on inside those objects to design the architecture in the first place. Each of those bricks is custom made by us to suit the needs of the current project, and the way they come together needs to make sense mathematically to avoid performance pitfalls.
Read that knowing nothing of lisp before and nothing clicked tbh.
When talking about tools that simplify writing boilerplate, it only makes sense to me to call them code generatiors if they generate code for another language. Within a single language a tool that simplifies complex tasks is just a library or could be implemented as a library. I don’t see the point with programmers not utilizing ‘code generation’ due to it requiring external tools. They say that if such tools existed in the language natively:
If code is to be reused you can just put it in a function, and doing that doesn’t take more effort than putting it in a code generation thingy. They preach how the xml script (and lisp I guess) lets you introduce new operators and change the syntax tree to make things easier, but don’t acknowledge that functions, operator overriding etc accomplish the same thing only with different syntax, then go on to say this:
What difference does it make that the syntax tree changes depending on your code vs the call stack changes depending on your code? Of course if you define an operator (apparently also called a function in lisp) somewhere else it’ll look better than doing each step one by one in the java example. Treating functions as keywords feels like a completely arbitrary decision. Honestly they could claim lisp has no keywords/operators and it would be more believable. If there is to be a syntax tree, the parenthesis seem to be a better choice for what changes it than the functions that just determine what happens at each step like any other function. And even going by their definition, I like having a syntax that does a limited number of things in a more visually distinct way more than a syntax does limitless things all in the same monotonous way.
Isn’t that how every programming language works? It feels unfair to raise this as an advantage against a markup language.
Data being code and code being data sounded like it was leading to something interesting until it was revealed that functions are a seperate type and that you need to mark non-function lists with an operator for them to not get interpreted as functions. Apart from the visual similarity in how it’s written due to the syntax limitations of the language, data doesn’t seem any more code in lisp than evaluating strings in python. If the data is valid code it’ll work, otherwise it won’t.
The only compelling part was where the same compiler for the code is used to parse incoming data and perform operations on it, but even that doesn’t feel like a game changer unless you’re forbidden from using libraries for parsing.
Finally I’m not sure how the article relates to code being math neither. It just felt like inventing new words to call existing things and insisting that they’re different. Or maybe I just didn’t get it at all. Sorry if this was uncalled for. It’s just that I had expected more after being promised enlightenment by the article
This is a person that appears to actually think XML is great, so I wouldn’t expect them to have valid opinions on anything really lol
On the other hand in certain applications you can replace a significant amount of programming ability with a good undertstanding of vector maths.
We must do different sorts of programming…
There’s a wide variety of types of programming. It’s nice that the core concepts can carry across between the disparate branches.
If I’m doing a particular custom view I’ll end up using
sin cos tanfor some basic trig but that’s about as complex as any mobile CRUD app gets.I’m sure there are some math heavy mobile apps but they’re the exception that proves the rule.
You should probably use matrices rather than trig for view transformations. (If your platform supports it and has a decent set of matrix helper functions.) It’ll be easier to code and more performant in most cases.
I mean I’m not sure how to use matrices to draw the path of 5 out of 6 sides of a hexagon given a specific center point but there are some surprisingly basic shapes that don’t exist in Android view libraries.
I’ll also note that this was years ago before android had all this nice composable view architecture.
Hah, yeah a hexagon is a weird case. In my experience, devs talking about “math in a custom view” has always meant simply “I want to render some arbitrary stuff in its own coordinate system.” Sorry my assumption was too far. 😉
Yeah it was a weird ask to be fair.
Thankfully android lets you calculate those views separately from the draw calls so all that math was contained to measurement calls rather than calculated on draw.
Tbf, that’s probably because most CS majors at T20 schools get a math minor as well because of the obscene amount of math they have to take.