this post was submitted on 26 Feb 2024
189 points (95.7% liked)
Programming
17432 readers
232 users here now
Welcome to the main community in programming.dev! Feel free to post anything relating to programming here!
Cross posting is strongly encouraged in the instance. If you feel your post or another person's post makes sense in another community cross post into it.
Hope you enjoy the instance!
Rules
Rules
- Follow the programming.dev instance rules
- Keep content related to programming in some way
- If you're posting long videos try to add in some form of tldr for those who don't want to watch videos
Wormhole
Follow the wormhole through a path of communities [email protected]
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
A lot people compleatly overrate the amount of math required. Like its probably a week since I used a aritmetic operator.
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.
Negl I absolutely did this when I was first getting into it; especially with langs where you actually have to import something to access "higher-level" math functions. All of my review materials have me making arithmetic programs, but none of it goes over a level of like. 9th grade math, tops. (Unless you're fucking with satellites or lab data, but... I don't do that.)
On the other hand in certain applications you can replace a significant amount of programming ability with a good undertstanding of vector maths.
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.
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
??
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.
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.
Sometimes when people see me struggle with a bit of mental maths or use a calculator for something that is usually easy to do mentally, they remark "aren't you a programmer?"
I always respond with "I tell computers how to do maths, I don't do the maths"
Which leads to the other old saying, "computers do what you tell them to do, not what you want them to do".
As long as you don't let it turn around and let the computer dictate how you think.
I think it was Dijkstra that complained in one of his essays about naming uni departments "Computer Science" rather than "Comput_ing_ Science". He said it's a symptom of a dangerous slope where we build our work as programmers around specific computer features or even specific computers instead of using them as tools that can enable our mind to ask and verify more and more interesting questions.
The scholastic discipline deserves that kind of nuance and Dijkstra was one of the greatest.
The practical discipline requires you build your work around specific computers. Much of the hard earned domain knowledge I've earned as a staff software engineer would be useless if I changed the specific computer it's built around - Android OS. An android phone has very specific APIs, code patterns and requirements. Being ARM even it's underlying architecture is fundamentally different from the majority of computers (for now. We'll see how much the M1 arm style arch becomes the standard for anyone other than Mac).
If you took a web dev with 10YOE and dropped them into my Android code base and said "ok, write" they should get the structure and basics but I would expect them to make mistakes common to a beginner in Android, just as if I was stuck in a web dev environment and told to write I would make mistakes common to a junior web dev.
It's all very well and good to learn the core of CS: the structures used and why they work. Classic algorithms and when they're appropriate. Big O and algorithmic complexity.
But work in the practical field will always require domain knowledge around specific computer features or even specific computers.
I think Dijkstra's point was specifically about uni programs. A CS curriculum is supposed to make you train your mind for the theory of computation not for using specific computers (or specific programming languages).
Later during your career you will of course inevitably get bogged down into specific platforms, as you've rightly noted. And that's normal because CS needs practical applications, we can't all do research and "pure" science.
But I think it's still important to keep it in mind even when you're 10 or 20 or 30 years into your career and deeply entrenched into this and that technology. You have to always think "what am I doing this for" and "where is this piece of tech going", because IT keeps changing and entire sections of it get discarded periodically and if you don't ask those questions you risk getting caught in a dead-end.
He has a rant where he's calling software engineers basically idiots who don't know what they're doing, saying the need for unit tests is a proof of failure. The rest of the rant is just as nonsensical, basically waving away all problems as trivial exercises left to the mentally challenged practitioner.
I have not read anything from/about him besides this piece, but he reeks of that all too common, insufferable, academic condescendance.
He does have a point about the theoretical aspect being often overlooked, but I generally don't think his opinion on education is worth more than anyone else's.
Article in question: https://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
Sounds about right for an academic computer scientist, they are usually terrible software engineers.
At least that’s what I saw from the terrible coding practices my brother learned during his CS degree (and what I’ve seen from basically every other recent CS grad entering the workforce that didn’t do extensive side projects and self teaching) that I had to spend years unlearning him afterwards when we worked together on a startup idea writing lots of code.