Dynamic typing is insane. You have to keep track of the type of absolutely everything, in your head. It’s like the assembly of type systems, except it makes your program slower instead of faster.
Nothing like trying to make sense of code you come across and all the function parameters have unhelpful names, are not primitive types, and have no type information whatsoever. Then you get to crawl through the entire thing to make sense of it.
What happens when you coerce a string to a date-and-time but it’s not valid?
Where I’m from (Rust), error handling is very strict and very explicit, and that’s how it should be. It forces you to properly handle everything that can potentially go wrong, instead of just crashing and looking like a fool.
When you say user, you mean a user of a function? In that case PHP would throw a TypeError, and presumably only happens when developing/testing.
If you mean in production, like when submitting a form, an Exception may be thrown. In which case you catch it and return some error message to the user saying the date string is invalid.
By “user” I mean the person who is using the application.
Using exceptions for handling unexceptional errors (like invalid user input) is a footgun. You don’t know when one might be raised, nor what type it will have, so you can easily forget to catch it and handle it properly, and then your app crashes.
If you don’t add comments, even rudimentary ones, or you don’t use a naming convention that accurately describes the variables or the functions, you’re a bad programmer. It doesn’t matter if you know what it does now, just wait until you need to know what it does in 6 months and you have to stop what you’re doing an decipher it.
Let’s take this one step further. I should be able to get the core ideas in your code by comments and cs 101 level coding (eg basic data structures, loops, and if/then).
Self documenting code is infinitely more valuable than comments because then code spreads with it’s use, whereas the comments stay behind.
I got roasted at my company when I first joined because my naming conventions are a little extra. That lasted for about 2 months before people started to see the difference in legibility as the code started to change.
One of the things I tell my juniors is, “this isn’t the 80s. There isn’t an 80 character line limit. The computer doesn’t benefit from your short variable names. I should be able to read most lines of code as a single non-compound sentence in English with only minor tweaks and the English sentence should be what is happening in most of those lines of code.”
I, too, remember the days before ultra high definition ultra wide monitors.
I thought this argument was bogus in the 90s on a 21" CRT and the argument has gotten even less valid since then. There are so many solutions to these problems that increase productivity for paltry sums of money it’s insane to me that companies don’t immediately purchase these for all developers.
You have a point, devs should be using multiple large monitors. I will often need to have 3-4 files open at once, plus some browser windows. Having some limit on line length helps with this and for fighting code complexity.
I have a massive ultrawide and I still 100% believe in line limits. Long linea are harder to read in general but even with a limit of 100 I frequently have 3 files opened next to each other and I can’t read entire lines easily. Line limits just aren’t about the size of the monitor and I can’t believe people still say that.
This is why code review exists. Writer’s can’t always see what’s wrong with their work, because they have the bias of knowing what was intended. You need a reader to see it with fresh eyes and tell you what parts are confusing.
That’s not to say you shouldn’t try to make it readable in the first place. But reviewing and reading other people’s code is how you get better.
My take is that no matter which language you are using, and no matter the field you work in, you will always have something to learn.
After 4 years of professional development, I rated my knowledge of C++ at 7/10. After 8 years, I rated it 4/10. After 15 years, I can confidently say 6.5/10.
This isn’t just the case with programming languages… Understanding how complex something is, is irriversible. Once you reach that plateau you will always know how much there is you don’t know.
Amen. I once had an interview where they asked what my skill is with .net on a scale of 1 - 10. I answered 6.5 even though at the time I had been doing it for 7 years. They looked annoyed and said they were looking for someone who was a 10. I countered with nobody is a 10, not them or even the people working on the framework itself. I didn’t pass the interview and I think this question was why.
Your mistake was giving them an answer instead of asking how the scale was setup before giving them a number. Psychologically, by answering first your established that the question was valid as presented and it anchored their expectations as the ones you had to live up to. By questioning it you get to anchor your response to a different point.
Sometimes questions like this can be used to see how effective a person will be in certain lead roles. Recognizing, explaining and disambiguating the trap question is a valuable lead skill in some roles. Not all mind you… And maybe not ones most people would want.
I was kicking myself for days afterwards for not doing exactly as you said. I’m not good at these types of interview questions in the moment. Also before that was the tech interview classic of asking a bunch random trivia questions, which I actually nailed. Also this was for dev II position.
I definitely dodged a bullet though. Some months later I got hired at a different company for 30k more.
Did your interviewer profess to be a 10 in .net, otherwise how would they know what that looks like? I was told that I’m unsuitable as a programmer of PLC because I never used their software before. That I write the algorithms that go into a PLC was not sufficient. These people are looking for unicorns but find donkeys everywhere they look.
He claimed everyone at dev II and higher was a 10 in their company. Complete dunning Kruger. I have no doubt I could’ve understood and worked on whatever software they have.
I agree with your first point, but pretty strongly disagree with the other two. Code review is critical. Devs should be discussing changes and design choices. One Dev can not be all things all the time and other people have experience you do not or can remind you of things you forgot. Programming language absolutely matters when you’re not the only dev on the team.
If the design of a code change is bad, noticing that in the PR stage is not desirable. It should be discussed before someone actually went ahead and implemented it. It can also happen if people misunderstand the architecture, but again, that should be cleared up before actually implementing a change. Code style should be enforced automatically, as should test coverage and performance. Code review is also pretty bad at finding bugs from my experience. That imo leaves very few things where code review is useful that are not nitpicking.
As for programming languages, the amount does matter for individuals and for teams/organisations. A developer who can only use a single language is not very good, and using a many different languages within the same team is not good either.
Code review is overrated and often poorly executed, most things should be checked automatically (review should still be done though)
I think part of this is caused by the fact that a lot of people are bad at code reviews so they focus on things that a linter could have told you. Being able to read code isn’t necessarily the same skill as being able to write it – as evidenced by the knee jerk reaction to throw out any coffee we didn’t write ourselves.
I still create code reviews when I’m working on a project alone because it gives me a different perspective on the changes I’ve made.
It’s not that most people are bad at it, they are just out of context.
Like, I am completely swamped with a completely different business area of the code, besides checking for obviously dumb things, what can I really tell about a diff to a very separate part of the code which I may have never worked on before, with business requirements I don’t understand as I was not part of the 10 meetings that happened between the dev of the given ticket and BAs?
But does it have to be? I haven’t touched non-web GUIs since 15 years, so my perspective on this is limited. And web frontend is not what I would call a well designed system for it’s current purpose.
Imo reviews are more for checking that someone didn’t drop malware into the code base. It’s rare that I get a good review that goes beyond checking for malice.
I’ve been wanting to make my applications easier to test. The issue is, I don’t know what to test. Often my issues are so trivial I notice them immediately.
What are some examples of common things in, let’s say a web server, that could be unit tested?
Good questions, I could probably write a lot, but I’ll try to keep it short. I usually apply TDD and there are different schools of thought within it about how to structure the development process. But no matter how exactly you do it, if you focus on writing the tests while writing your code, you won’t end up with an application that you then have to figure out how to test.
what to test
Well, what is the application supposed do? That is what you test, the behaviour of the application.
So in a codebase without any tests, the first thing you should write a test for is the happy path. That will probably not be a unit test. So for the web server example, set it up in a test with a file, start it and check if it serves that file.
Then you can add tests for all the error cases and for additional functionality. You can write unit tests for individual components. The ideal places to test are interfaces with clear boundaries. Ideally you should not have to look at the code of a method to be able to write a test for it. In reality that’s not always so easy, especially in existing code bases, but if you have to set up more than one mock, it tends to lead to brittle tests.
Every time you encounter a bug/issue, reproduce it in a test first. And do measure code coverage, but don’t make it a target, just check for places that are lacking.
I don’t mean it doesn’t work for larger projects. Just that it’s a pain to understand other’s code when you have almost no type information, making it, to me, a no go for that
Larger projects in Python (like homeassistant) tend to use type-hints and enforce them through linters. Essentially, these linters (with a well-setup IDE) turn programming in large Python projects into a very similar experience to programming a statically typed language, except that Python does not need to be compiled (and type-checked) to run it. So you can still run it before you have satisfied the linters, you just can’t commit or push or whatever (depending on project setup).
And yes, these linters and the Python type system are obviously not as good as something like a Go or Rust compiler. But then again, Python is a generalist language: it can do everything, but excels at nothing.
Yes, in a good dev workflow mypy errors will not pass basic CI tests to get merged. Types are not really a problem in modern Python workflows, you can basically have a better type checker than Java out of the box (which can be improved with static analysis tools). The biggest problem with Python remains performance.
Go and rust are also generalist languages. Basically all main stream programming languages are and are equally as powerful (in terms of what they can do, rather than performance) as each other as they are all Turing complete. So you can emulate c in python or python in c for instance).
Anything you can do in python you can do in basically any other mainstream language. Python is better at some niches than others just like all other languages are with their own niches - and all can be used generally for anything. Python has a lot of libraries that can make it easier to do a large range of things than a lot of other languages - but really so do quite a few of the popular languages these days.
I mean, it’s still a very nice language. I can see someone, marveled by that, would endeavor to make bigger things with it. I just don’t feel it scales that well.
My own hot take is that I hear this criticism of Python a lot, but have never had anyone actually back it up when I ask for more details. And I will be very surprised to hear that it’s a worse situation than Java/TypeScript’s.
We used to have a Python guy at my work. For a lot of LITTLE ETL stuff he created Python projects. In two projects I’ve had to fix up now, he used different tooling. Both those toolings have failed me (Poetry, Conda). I ended up using our CI/CD pipeline code to run my local stuff, because I could not get those things to work.
For comparison, it took me roughly zero seconds to start working on an old Go project.
Python was built in an era where space was expensive and it was only used for small, universal scripts. In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
In that context, having all packages be “system-wide” made sense. All the virtual env shenanigans won’t ever fix that.
Sorry, but you’ll need to explain this a little bit more to me. That’s precisely what virtual env shenanigans do - make it so that your environment isn’t referencing the system-wide packages. I can totally see that it’s a problem if your virtual env tooling fails to work as expected and you can’t activate your environment (FWIW, simply old python -m venv venv; source venv/bin/activate has never let me down in ~10 years of professional programming, but I do believe you when you say that Poetry and Conda have broken on you); but assuming that the tools work, the problem you’ve described completely goes away.
The endless packaging solutions for python is exactly the flaw that they’re talking about.
Packaging a python application to work over an air-gap is extremely painful. Half the time its easier to make a docker container or VM just to avoid the endless version mismatch pain.
I don’t think the length of program matters so much, especially with type hints making it easier to maintain larger projects.
That being said, it’s pretty well known in the community that distributing any kind of end user software is a nightmare with python (though there’s a small group of people who insist that it’s not that hard to get people to install python to run their program. Those people are nuts).
The biggest reason I use python for as many projects as is practical, though, is because it has an incredible community that I love to interact with. Unless I truly need something to be scalable, python is always going to be my choice of hammer.
SPAs are mostly garbage, and the internet has been irreparably damaged by lazy devs chasing trends just to building simple sites with overly complicated fe frameworks.
90% of the internet actually should just be rendered server side with a bit of js for interactivity. JQuery was fine at the time, Javascript is better now and Alpinejs is actually awesome. Nowadays, REST w/HTMX and HATEOAS is the most productive, painless and enjoyable web development can get. Minimal dependencies, tiny file sizes, fast and simple.
Unless your web site needs to work offline (it probably doesn’t), or it has to manage client state for dozen/hundreds of data points (e.g. Google Maps), you don’t need a SPA. If your site only needs to track minimal state, just use a good SSR web framework (Rails, asp.net, Django, whatever).
I do a lot of PHP, so naturally my small projects are PHP. I use a framework called Laravel, and while it is possible to use SPAs or other kinds of shit, I usually choose pure SS rendering with a little bit of VueJS to make some parts reactive. Other than that, it is usually, just pure HTML forms for submitting data. And it works really well.
Yeah yeah, they push the Livewire shit, which I absolutely hate and think is a bad idea, but nobody is forcing me, so that’s nice.
I loathe JavaScript heavy websites, especially when used for forms. Don’t break autofill and copy/paste. And don’t complain about the format just because I pasted! Seriously, why is pasting text in the correct format triggering some JavaScript framework? It all seriously gets to me.
With that said, I really like Hotwire. HTML over the wire is bliss. Stimulus is perfect for sprinkling non-invasive JavaScript throughout an application.
Preferring server side rendering is an interesting topic
Client side renderering is currently the preference because the company gets to offload the compute costs of their servers onto the clients’ devices
As long as every website has a profit motive, even if it’s just a single person trying to save some money on their AWS bills, server side rendering will never become the norm
The difference between generating JSON and generating HTML is minimal for the server, doesn’t seem to me like server side rendered sites have significantly higher server compute costs. Also generally for SPAs, the server has to replicate whatever flow is happening on the client anyway to keep state in line (since the client can’t be trusted)
The difference between generating JSON and generating HTML is minimal for the server
That should be true, but have you looked the HTML of any “modern” site? Dozens of nested elements, each tagged with multiple lines of attributes. Generating that is probably 10x the cost of generating the JSON.
Plus, with server side rendering you also have to recompute the HTML for the entire site, which often contains a whole bunch of non-trivial queries as well.
Plus, with server side rendering you also have to recompute the HTML for the entire site, which often means re-computing a whole bunch of non-trivial queries as well.
This is actually why I really like HTMX, you load a page once, then make AJAX requests that return html which you can use to replace or add to the DOM. It provides an interactive front end where the backend provides full rendered html partials. Simplifies the entire application by keeping logic and state only on the server, which means you never have to worry about synchronizing front-end and backed state.
I’m still hoping for browsers to become some kind of open standard application environments and web apps to become actual apps running on this environment.
I’m thinking more along the line of ubiquitous offline first PWAs. Imagine google doc running offline in a browser and being able to edit local docs directly. I guess secure file system access is one of the major road blocks, though I’m not sure of the challenges associated with coming up with a standard for this.
Actual hot take, Blazor is awesome, it is like Microsoft looked into ASP.NET Forms, ASP.NET MVC and Razor, and bundled it to one quick framework to do simple WebApps.
Counter hot take, I do actually like Blazor but it has limitations due to how immature web assembly still is. It also does not solve the problem of being a big complex platform that isn’t needed for small simple apps. Of the half dozen projects I’ve written in Blazor, I’d personally re-write 3 or so in just Razor Pages with Htmx.
I forgot where I heard this, but at one point around the same time, Microsoft was trying to get BASIC embedded into webpages for Internet Explorer as a competitor to JavaScript.
What do you mean going to? Internet Explorer supported VBscript, which was a “competitor” to Javascript. Though being locked to ie was a hindrance to adoption. That, and it was based on vb.
The JavaScript ecosystem is made worse by the legions of “developers” in it which amount to bro-velopers that put no thought into if something is needed before they create it. There’s a strong overlap between the idiots in crypto and JavaScript developers that needs to be decoupled drastically.
The best codebase I have ever seen and collaborated on was also boring as fuck.
Small, immutable modules.
Every new features was coded by extension (the ‘o’ in S.O.L.I.D)
All dependencies were resolved by injection.
All the application life cycle was managed by configurable scopes.
There was absolutely no boiler plate except for the initial injectors.
All of the tests were brain-dead and took very minimal effort to write. Tests served both as documentation and specification for modules.
“Refactoring” was as simple as changing a constructor or a configuration file.
All the input/output of the modules were configurable streams.
There is more to it, but basically, it was a very strict codebase, and it used a lot of opinionated libraries. Not an easy codebase to understand if you’re a newbie, but it was absolutely brain dead to maintain and extend on.
Coding actually took very little time of our day, most of it consisted of researching the best tech or what to add next. I think the codebase was objectively strictly better than all other similar software I’ve seen and worked on. We joked A LOT when it came time to change something in the app pretending it would take weeks and many 8 pointers, then we’d casually make the change while joking about it.
It might sound mythical and bullshity, and it wasn’t perfect, it should be said that dependency injection often come in the form of highly opinionated frameworks, but it really felt like what software development should be. It really felt like engineering, boring and predictable, every PO dreams.
That being said, I given up trying to convince people that having life-cycle logic are over the place and fetching dependencies left and right always lead to chaos. Unfortunately I cannot really tell you guys what the software was about because I am not allowed to, but there was a lot of moving parts (hence why we decided to go with this approach). I will also reiterate that it was boring as fuck. If anything, my hot take would be that most programmers are subconsciously lying to themselves, and prefer to code whatever it is they like, instead of what the codebase need, and using whatever tool they like, instead of the tools the project and the team need. Programming like and engineer is not “fun”, programming like a cowboy and ignoring the tests is a whole lot of fun.
I never got so far, but had a system built which some parts of what you described. It was incredibly relaxing to develop with it. Our take as a team was: boring is better, we don’t want to be paged on weekends.
This! Software engineering suggests a certain professionalism wich unfortunately is hard to find. From an accessibility point of view I am simply not able to participate in these cowboy style events for I do not have the mental capacity to do so. Ironically I have been able to work more effectively than others by focussing on quality.
Coincidentally I published some of my work earlier this week. It’s an opinionated library dictating the structure of your core domain. In return it completely decouples infrastructure. This way you do not really have to touch infra at all during day to day operations, which simplifies things immensely! As the domain exists at the very core of most software projects, it greatly impacts the way everything else is designed as well.
I’m not a programmer (I tried learning programming and unity but got lazy so…) but when I learned about if-then statements, the second one seemed like the way it’s supposed to be; I mean it looks so clean and simple. Do actual programmers prefer the first method?
Compiler checked typing is strictly superior to dynamic typing. Any criticism of it is either ignorance, only applicable to older languages or a temporarily missing feature from the current languages.
Using dynamic languages is understandable for a lot of language “external” reasons, just that I really feel like there’s no good argument for it.
Yeah the error list is my friend. Typos, assigning something to the wrong thing or whatever is fixed without having to run the code to test it. Just check the error list and fix any dumb mistakes I made before even running the thing. And I can be confident in re-factoring, because renaming something is either going to work or give a compiler error, not some run-time error which might happen in production weeks later.
I do believe that static typing is at least a local optimum, but I am still not entirely convinced. Rich Hickey is a very convincing presenter and I can’t help but think that he is on to something — with Clojure the chosen direction is contract-typing, which is basically a set of pre- and post-conditions for your functions that are evaluated at runtime. Sure, it has a cost and in the extremes they are pretty much the same as dependent types, but I think it is an interesting direction — why should my function be overly strict in accepting a “record” of only these fields?
Blame management for that. I implemented Scrum in a project that I took over without any changes to the framework and it is great. We are able to keep a healthy work life balance, no overtime, good relationship between the product and the engineering team, and the most important thing is on time feature delivery.
Not an Agile issue, but a “people fucking up Agile” issue. The priesthood of MBAs will adopt whatever terms people like and just hammer them into place to keep doing the same old shit.
I have experienced this but I think that’s the fault of the people implementing it.
For instance, I have been in a 4-person team where the daily meeting took 30 minutes and people often rehashed discussions they had on the previous day. I have also been on a 10-person team where the meeting took 10 minutes on a bad day
Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.
Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.
In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.
Oh totally seen it work myself but I don’t know that it was agile that worked as much as they had a kickass team.
Some teams just jive well. They communicate, they know what each other is doing, and they can plan with minimal waste. And when it’s successful that’s across all roles not just the devs.
In my opinion those teams would have succeeded in waterfall, kanban or their own home brewed strategy as well.
I know it’s popular to bitch on php but I’ve found it’s all for the wrong reasons. The vast majority of the internet still runs on it and it’s a breeze to work with, I love it. It’s safe, it’s fast, it’s great.
I’ve worked with a variety of JavaScript frameworks and they all give me headaches.
It’s just that it’s an ugly and weak language, overly verbose, and riddled with inconsistencies. There are few good things you can do in PHP without huge frameworks.
Not sure what qualifies as ugly but I find PHP codes much easier to read than JavaScript (if that is what you meant)
If with weak you mean weak typed then you’re partially correct: most of it can be typed and ever since … I dunno, years ago, I’ve worked exclusively with strict typing. Things have improved considerably on that front
What part is verbose? Genuine curiosity
The inconsistencies are true. It’s also PHP’s strength that they kept everything like that and kept everything compatible. Every JavaScript framework I have worked with caused the weekly update nightmare headaches where 5 bugs were resolved, but now 10 more were added due to changing method calls. I hated it and I love PHP for at least keeping that consistency. Over time they have worked little by little to mitigate things but at the core, yes, you have function call inconsistencies. However, good editors these days for that for you and tell you the function name and give you the parameter order.
Then that there are few good things you can dowithout frameworks is nonsense.
If you want to do it right you use a framework, but that goes for every language. But I’ve sen and worked on (admittedly a horrible) system that would scrape millions of pages per day and its first version was just hacked together code. Ugly but super quick and simple, no frameworks. I’ve built many similar systems and sites like it over the years.
Now I recently built my own new framework in PHP, all strict, and it’s just fast and beautiful
You’re comparing to only JavaScript, have you worked with another language like python, ruby, lisp, rust? Maybe then you’d see what I mean.
By verbose I mean that mostly PHP lacks syntactic sugar, mostly it lacks powerful features of other languages. You can mostly write very simple procedural code.
Well I compare to JavaScript because that’s what most people bring up. On web development, I guess JavaScript is the biggest competitor.
I’ve worked with many languages. I even worked with assembly for a while in another life over 25 years ago, I worked with visual basic, .net, c, c++, Java, JavaScript and it’s many frameworks, loads other more obscure languages too, and I’ve played with some python over the years. Still though, php has my favorite since a loooong time
Can you give an example of missing syntactic sugar or features that are missing?
Type hinting? There. Traits? There. Interfaces? There. I could go on but PHP has all these features that people keep saying are missing.
I’m not saying you don’t have to like PHP, everyone likes there own labgua and that’s fine.
However, people keep making shit up about phpt and then use that shit to smear it and it’s annoying. PHP is great for web sites, small and complicated, it’s great for command line scripting, it’s great for a large list of tasks and it seems that what you need is there.
It doesn’t really count if you need a huge framework for it. Frankly I never saw PHP used well, and I never saw it do anything better than other languages can do.
Hahaha this is great! All points are basically entirely obvious and common sense and then you hit us with that ridiculous statement about PHP. Outrageous!
From what I’ve seen is that 99% of the PHP hate is people parroting slogans others came up with, and the rest is that there are inconsistencies with the function signatures.
That last part is very true, of course, but not really an issue with modern editors as they will already tell you what’s expected. On the other hand, the inconsistencies are still there for a reason: compatibility. JavaScript what’s a nightmare to work with because every week an update would break shit because of changing method signatures in JavaScript packages. PHP always worked and remained working because it changed so little in that respect.
In all other areas it hugely improved and matured over the years, just like all programming languages.
Honestly, “it’s better than JavaScript” is a pretty low bar.
I don’t like PHP because I think the syntax is ugly and I’ve only used it on systems that are old and a pain to maintain, but I’ll also very freely admit that I have absolutely not written enough PHP to have an informed opinion on it as a language.
True enough on JavaScript but I mention it because people always take that for comparison. I’ve used it for hundreds of projects now and for me it’s become my default goto language because I can slap together anything with it. It now has good (optional but encouraged) type safety, which greatly improves code quality so yeah… love it
PHP grew “organically” out of a perl library. There was never a consistent plan/idea about the set of abstractions it provides, the type system, builtin functions etc… Everything has been bolted on here and there, some additions good, some bad, some terrible pitfalls. A language with builtin operators that are basically unusable (comparison!) and where some functions return false when the input is invalid, is really fundamentally broken. I agree that many of the worst failures of PHP have been (kind of) fixed after PHP5 and that’s nice for large existing PHP codebases (mediawiki, wordpress, nextcloud, typo3). But I just can’t understand why one would start new projects in PHP in a world where so many very well designed and well thought through languages exist.
Yes, PHPs beginnings were very messy and even today we see results from that.
But PHP was and remains hugely popular because it’s so easy and fast to work with and today it is very nicely designed and worked out. Yeah there are many details open but editors help you out with that. Other languages may be more consistent at the core but they have their own issues. JavaScript is a nightmare to work with for me, personally, but I o dont bitch about it every opportunity I get.
I guess I’m just slightly annoyed with people complaining about PHP while it’s just another language and it’s success speaks for itself
Well, if it comes to web development (my main focus since the last decade at least) I think it’s fair to say there is little that nears PHP (or, begrudgingly, JavaScript)in functionality. With current frameworks (my own included) I can churn out highly complicated and fast sites in no time. Can’t say that for many other languages.
Java? “Fast”? Lol no. “No time”? Lolol no.
Python? Honestly I have too little experience with it to say, but at least frameworkoptions are much more limited anyway
If the method does a long thing, the keep it long. I do a lot of data analysis and simulation, and so often people who came before had this urge to shorten methods, so we get:
<span style="color:#323232;">def do_calculation(N, X, y, z, a, b, c):
</span><span style="color:#323232;"> # Setup stuff
</span><span style="color:#323232;"> for i in range(N):
</span><span style="color:#323232;"> calclation(X[i], y, z, a, b, c)`
</span>
Sometimes there’s a place for that, like if calculation could be swapped for a different function, or if calculation is used all over the program. It’s a pretty good clue that something is up though when the signatures are almost identical. Of course, that has just led to people writing:
Your average Microsoft error “error 37253” is worthless to me
This is a security thing. A descriptive error message is useful for troubleshooting, but an error message that is useful enough can also give away information about architecture (especially if the application uses remote resources). Instead, provide an error code and have the user contact support to look up what the error means, and support can walk the user through troubleshooting without revealing architecture info.
Another reason can be i18n/l10n: Instead of keeping translations for thousands of error messages, you just need to translate “An Error Has Occurred: {errnum}”
Those benefits both make sense, but are those really the original motivation for Microsoft designing the Blue Screen of Death this way? They sound more like retroactive justifications, especially since BSODs were around well before security and internationalization were common concerns.
Linux has something similar, kernel panics. However, with Linux you get useful information dumped on your screen.
Nothing gets logged on Linux either, just like windows and that makes sense. The kernel itself messed up and can’t trust its own memory anymore. Writing to disk may cause you to fuck up your disk, so you simply stop everything.
Still though, Linux dumps useful info whereas windows just gives you this dumb useless code.
PHP the language has become pretty nice, but I recently had to work with a PHP CMS deployment, and it was an absolute pain to do. PHP frameworks seem to still exist in a world where you manually upload code to a manually configured server running apache. Dockerizing the CMS (uses Symfony) is/was an absolute pain.
I know that there are loads of solutions out there that can do this for you, though I don’t have much experience with it myself directly. Not a great fan of docker, still, as it’s not a requirement and in many cases that extra piece that fails and then is a PITA to fix.
I’ll look to include it in my own framework, though
But you can set a tab width instead so any developer editing the code can adjust the indentation width to his liking, without changing the actual files contents and having to worry about setting the editor up to insert the right amount of spaces.
Tabs are literally designed for aligned indentation, and they’re configurable for clientside viewing. There is no excuse for spaces. I don’t care if your goddang function arguments line up once they spill out onto another line. You’ve got deeper problems.
Tabs are designed for tabulation (hence the name), not indentation. The side effect is that a tab’s length changes based on its position in a line, which is terrible for programming. If you use tabs in the Python REPL, it looks like this:
<span style="color:#323232;">>>> def frobnicate_all(arr):
</span><span style="color:#323232;">>>> for item in arr:
</span><span style="color:#323232;">>>> frobnicate(item)
</span>
The horizontal tabulation character moves the cursor to the next column which is a multiple of the tabulation length. See the examples here: en.m.wikipedia.org/wiki/Tab_key
The horizontal tabulation character moves the cursor to the next column which is a multiple of the tabulation length. See the examples here: en.m.wikipedia.org/wiki/Tab_key
Yes
Clearly the whitespace produced by each tab character has a different length.
No, each tab has the same size, the text rendered over the top of the tabs are not the same size.
Always remember the golden rule: Tabs for indentation, spaces for alignment.
Tab goes to the next stop, the same way newline goes to the next line. Exactly the same way. If you write more text before the next line, the amount of whitespace shrinks. That doesn’t mean the “length” of a newline changes. It always goes one line.
Every IDE and editor (gui and tui) I’ve used has always come preconfigured with a tab-size of 4.
The only thing I’ve ever experienced having a tab-size of 8 was github, and I thought that was just a problem with a setting from github’s size that I quickly set back to 4.
It seems that tui editors come with tab-sizes of 8 only when a config isn’t provided, and every environment I’ve used where I’ve used a tui editor has always come with sensible configs (for things like config location, language recognition for syntax highlighting, etc…) including a tab-size of 4.
Add comment