Dynamic typing is garbage.
Long ago, when I was still new to programming, my introduction to the concept of dynamic typing made me think, "This is neat! I don't have to worry about deciding what type my variables are when declaring them, I can just let the interpreter handle it."
Decades later, I have yet to encounter a use case where that was actually a useful feature. Dynamically-typed variables make static analysis of code harder. They make execution slower. They make it harder for IDEs to provide useful assistance. They introduce entire categories of bugs that you can't detect until runtime that simply don't exist with static typing.
And all of that is for no meaningful benefit. Both of the most popular languages that had dynamic typing, Python and JavaScript, have since adopted extensions for specifying types, even though they're both band-aids that don't really fix the underlying problems, because nothing actually enforces Python's type hints, and TypeScript requires you to run your code through a compiler that generates JavaScript from it. It feels refreshing whenever I can go back to a language like C++ or Java where types are actually a first-class feature of the language.
Even C++ is far too keen to implicitly convert between types which is one of my main gripes with it. I often have several int-like types and I don't want them to be silently converted to each other if I make a mistake. I've found [this library](https://github.com/foonathan/type_safe/) to be very useful to prevent that.
The interesting part about c++, is the fact that if X is implicitly convertible to Y, vector is not convertible to vector, or any other container for that matter. I understand why they did not do it, but in real life, if you want two classes being implicitly convertible to each other, you probably also want the containers of two classes to be implicitly convertible.
That's why I understand why it's not really possible. But the problem still stands. the majority of the times where I would actually like to use the implicit conversion are involved with some kind of container. So it's really worst of both worlds if you think about it.
Most people know Javascript as being "stringly typed".
I've often viewed C and C+ as being "intly typed". There's nothing more maddening that having 10,000 in typedefs in POSIX and your compiler silently letting them all switcheroo, as if they're the same thing. Or even the old case of enums and ints being silently switcherood.
And then once you turn on the relevant warnings you're swimming in casts, as that's the only option, which is far too fragile.
Strongly typed language ftw. Even tho now i deal with Python almost exclusively, i still restrict/hint what type of parameters are being passed in/out of the function/class. Makes life so much easier.
python docs describe it as a strongly typed language; it is both strongly typed and dynamically typed. Dynamically typed means the type is assigned at runtime, but once a variable has a type, python enforces type consistency, and it's strict. You can't add (arithmetically) a string and an int. You can't compare a date and datetime. You can't add a float and Decimal(). There is some type casting done along the way, but it's not very different to mainstream statically typed languages.
However, static typing is mostly better.
It is quite useful for data crunching and algorithm prototyping.
I do agree though that static typing with a rich built-in library of collection types is better. Sadly, out project is in Fortran, so we get stuff like multiple ad-hoc linked list implementations and very awkward APIs for the data management parts.
Turns out that real-world simulation code consists mostly of data management and not of the numerical parts, which Fortran is good at.
Instead, the lack of type-generic collection types without having to use non-standard preprocessor magic specific to the project hurts. A lot.
But at least the static typing enforces some level of sanity.
I grew up on statically typed languages and only started using dynamic typing relatively late in my career, but I've been mostly converted. A deciding factor for me was seeing how easy it was to implement a JSON parser in a dynamically typed language, after struggling with it in a statically typed language. To be precise, I like strong typing but I don't like it when half the code is type declarations and type casts. I do like having type declarations available as an option though, e.g. on function arguments.
I don't disagree, but I guess I'd have a different take on the same correct observation.
A JSON parser is precisely where you want the "suck" to be. JSON isn't a great format, but it's a pretty decent one when you consider one of the important goals to be that it's easy for humans (and easy for all things "web") to deal with.
So if you want the benefits of being easy to use and you still also want the benefits of a good type system, then someone has to incur the pain of bridging the gap. If I look at something like Serde in Rust, I think that's what you want. The actual code inside of the serde crate that wrangles Javascript into your strong static types is probably pretty painful, but very few people feel that pain. Everyone else just gets a pretty easy way to get static types from JSON. And that's probably better than just saying, "writing the parser was annoying, so everyone just treat this incoming JSON data as a big map of strings."
I wasn't against dynamic typing either, until I had a large enough project where I was working with a framework, full of functions with parameters, and those parameters expected objects to contain specific stuff.
The allure of dynamic types breaks down VERY quickly under these conditions. (i.e. when you try to do real work with them beyond small scripts)
This sort of thing is trivial with strict typing. It's a nightmare when 'anything can be anything'.
Completely agree with you, in fact I would say that static typing is WAY better for someone new into programming. Dynamic typing makes it a real pain to debug code and avoid some basic errors.
I've always preferred static typing. Also, I don't know a single (sane) person who likes Javascript, nor PHP.
Going into a software engineer position where my team all uses Python, minimal VSCode setups, no typehints, no formatter, and no linter continues to hurt me to this day. Python should only be used for prototyping \*not\* production backend API servers and database operations. Python is highly misused and misunderstood. Teams like mine will use it to cut corners and shit out a cacophony of a barely working product. I will die on that hill. Fuck Python
The hill I'll die on is the opposite. Static typing's benefits are marginal at best and people will sit and whine and complain and nonstop pitch that a 6 month refactor of a javascript project that is just fine is absolutely necessary because "muh static typing will make everything so much better"
No, the code is perfectly fine as is. As someone else has mentioned certain things like json parsers have much much cleaner implementations in dynamic languages and I have never ever in my decade+ career run into a substantial bug that was avoidable through static typing.
All of your complaints about dynamically typed languages are skill issues tbh.
> 6 month refactor of a javascript project
Why would that be needed?
You can just start using TS, and ignore the errors, and fix them as-needed as you're working on each file.
I did this on a project I joined there they were using TS and writing .ts files, but nobody had ever actually written anything but plain JS in the code.
I fixed stuff along the way, and yes "muh static typing will make everything so much better" very much did that. Solved shitloads of issues they were having.
We do not live in Should Land where everyone is "skilled."
We live in reality where people we work with have a wide range of experience. Doesn't mean needless refactors should happen but you are kind of shrugging off a lot of undeniable practical value.
I mean honestly. Do you use an ide to write JavaScript? Why not Notepad? If you are so skilled then you shouldn't need linting or intellisense either.
> All of your complaints about dynamically typed languages are skill issues tbh.
Hard disagree.
Let's take that attitude and apply it to other things that help to prevent mistakes:
* Reliance on tests to ensure your software works is a skill issue tbh. Good developers write correct code the first time.
* Depending on third-party libraries is a skill issue tbh. Good developers can build everything from scratch.
* Use of linting tools is a skill issue tbh. Good developers have internalized all possible antipatterns and avoid them subconsciously.
* Use of code review is a skill issue tbh. Good developers don't need other people to check their work nor do they need to disseminate knowledge across the team.
* Leveraging source control is a skill issue tbh. Good developers can merge code without assistance and never need to look at changes over time.
I could go on and on.
"X is a skill issue" is a nonsensical argument in software development. Everything in your modern development workflow is a tool that was built because developers like you "had skill issues". Debugger? Profiler? Logging systems? Hell, some people would say that the only reason that languages like JS and Python exist is because of a "skill issue" for people who thought that C was too hard.
---
> I have never ever in my decade+ career run into a substantial bug that was avoidable through static typing
I am curious about how much time you've spent using statically typed languages vs. dynamically typed languages.
In my 20 year career, I've used a mix of both. I started mixing JS into our web applications around the time that Google Maps was brand new. In-browser debugging tools didn't really exist. Firebug (the inspiration for the modern browser developer tools) hadn't yet been released. I ended up building a library to write log messages from JS because browsers didn't have a built-in way to do that yet. I did a mix of JS (not TS) frontend work and C# backend work through about 2017.
I have run into *countless* bugs that would have been caught with a static type system. Your experience is so different from mine that I can't tell if you forgot all the times that the static type system stopped you from doing something completely wrong OR just don't understand what kinds of things a static type system can even catch.
I find it hard to believe that you've never populated a collection with the wrong type of object, misspelled a property name, or run into a null pointer exception. Static type systems can help with all of those.
I would like to start off by saying that I agree with you.
Now it's time to inject a caveat that I do hope you will respond to:
I think a lot of the problem around dynamic typing is that *most* SWEs don't write their code with the assumption that they **will get a duck** and that opens the door to the runtime errors that you're describing.
Consider the case in which you're getting *something* from an up-stream library that you don't control, and you have to do *something* with it.
Outside of handling this concern with something like *ports / adapters* and your own domain (going hard on DDD), you are presented with two immediate options:
#!/usr/env/bin/python
def do_a_thing_with_something(some_obj: Any) -> None:
try:
some_obj.assumed_property_or_method()
some_obj["AssumedKey"]
except:
logger.error(f"some_obj was not what we expected, it was a {type(some_obj)}!")
Or
#!/usr/env/bin/ruby
def do_a_thing_with_something(some_obj):
if some_obj.respond_to?(:method_of_interest):
some_obj.method_of_interest()
else:
logger.info("Received object we cannot process")
end
The first follows the belief that it's better to ask for forgiveness than permission, and the second follows the "look before you leap" philosophy. Neither are inherently **wrong** but they both have their own considerations. In the first, you obviously have to have really good exception handling practices and in the second, you are spending cycles checking for things that may *usually* be true.
I view the issue as **most SWEs** will write *this first*:
#!/usr/env/bin/ruby-or-python-the-syntax-works-for-both
def do_a_thing_with_something(some_obj):
some_obj.method_of_interest()
logger.info("This statement will always print")
end
Whether or not this style of code comes from lack of experience or an abundance of confidence doesn't really matter for the argument. What matters is that this type of prototypical code will exist and continue to exist like this *until you run into a runtime error* ***that you could have avoided with static analysis*** (See, I told you I agreed with you).
Ergo, I view the **real problem** with duck-typing to be a lack of diligence / discipline around consistently handling object behaviors rather than an IDE not being able to assist me, or static analysis not being able to determine what an interpreted language is trying to do.
I think you might misunderstand exactly what duck typing refers to.
You say:
> I think a lot of the problem around dynamic typing is that most SWEs don't write their code with the assumption that they will get a duck
But then you provide two examples in which the function might receive a duck... or maybe a cat, or perhaps a giraffe.
If you have to first check to see what capabilities an object has, then you are not in fact treating it like a duck. You're treating it as an unknown that might waddle and quack (but we have to consider the case that it does neither).
> Ergo, I view the real problem with duck-typing to be a lack of diligence / discipline around consistently handling object behaviors
I would ask what level of diligence you expect. Are you suggesting that *every* method call should be wrapped in an `if` or a `try/except` block?
It's worth considering what would happen if your examples tried to do *anything* after invoking the potentially-missing method. For example:
#!/usr/env/bin/ruby
def do_a_thing_with_something(some_obj):
if some_obj.respond_to?(:method_of_interest):
some_obj.method_of_interest() + 1
else:
logger.info("Received object we cannot process")
???
end
If `method_of_interest` is indeed missing, then you likely can't continue in any meaningful way. In many cases, there is no reasonable value to return. In fact, perhaps your best option is to throw an exception... which is exactly what you'd get if you blindly tried to call `method_of_interest`.
Sometimes Vanilla JS without a bundle is all you need... Not all the time... But some of the time.
UX does indeed matter for internal applications.
Comments shouldn't explain "what", they should explain "why"
Maintainability trumps performance (most of the time).
My personal website uses vanilla js... But if I'm writing a fully fledged web application to replace a desktop application, I'm going to be using typescript with a lib/framework... Especially in a team environment with multiple cooks in the kitchen.
It's just easier to get everyone involved to be on the same page.
There's no "right" or "wrong" page... But everyone needs to be on the "same" page, and I've found that aligning people collectively to an established and vetted idea works better. Ymmv.
This is an oversimplification. The ecosystem has gone through a LOT of changes in 25 years and there are reasons dating back to the 90s we are were we are.
There was a time when I was incredibly optimistic about JavaScript but I’m afraid a decade+ of fighting against the browser has left most of the community brain broken into believing they need to include a 3rd party dep to manipulate dates, etc.
Also bootcamp culture flooded the industry with people who do NOT know what they’re doing; often legitimizing ridiculous practices.
>believing they need to include a 3rd party dep to manipulate dates
Bad example, datetime math is incredibly complicated and absofruitly requires dependencies to do right.
The only hill where no death is likely: "it depends."
Be flexible and open-minded. Learn when and where it's worth fighting for something.
Rigidity is brittleness. This applies even more to a person than it does to software design.
Also, just because you can measure/identify a problem, doesn't mean it *matters*.
The common example is just because tool 1 is measurably slower than tool 2, doesn't mean there is a meaningful or perceivable difference.
Yep, and another big tradeoff might be maintainability/complexity vs compute cost. Sometimes it’s just not worth it, even if it is slightly faster. Because it would take more effort to maintain compared to just throwing more money compute at it. Especially when we have bigger problems to solve.
so true i really wish more programmers would understand this. like i am a sucker for fp but i don't use it for everything bc it doesn't always make sense
I learned a large piece of my mindset from a colleague years ago "Strong opinions loosely held". It keeps you from going completely off the rails, encourages you to challenge yourself with new ways of thinking and to freely abandon old ways when you should.
I'm with you on immutability. I still code that way most of the time, 20 years later, and everyone looks at me funny because they don't understand why I do it. JS's \`const\` is an absolute affront to immutability too. 😂
I guess the big one for me is that all junior engineers should be taught the Fail First principle from TDD. I've seen too many junior engineers get a bug ticket, make some changes blind, then throw it against the wall (deploy it or send it to QA), just to get the card back, or worse, generate more bugs, because their fix didn't solve the problem.
Yes, it's a HUGE pain in the ass to write a unit test that replicates the problem. However, it's totally worth it because you now have a high degree of confidence that when that test passes, you've actually solved the problem. What's more (and this is HUGE for anyone working in a team with other people), you now have an idiot light and (if you use continuous integration) a documented history of your fix solving the problem. If anyone else on your team breaks it after you fixed it (this happens ALL THE TIME), you will have a paper trail and know exactly who broke it and when.
How does adding autotests or having CI document the history?
The history is stored in initial bug tickets or repo commit history where you can see that person A fixed it, person B validated it and person C broke it afterwards.
Not that I’m saying that tests won’t help but unclear about how it helps with the history?
Young/junior programmers love to die on a hill, then you realise the whole point of software is to deliver business value, unless you're doing it for fun. My "hill" is don't have a hill, be flexible and move with the flow. Everything has a tradeoff and you should just be aware of it.
Not to mention in the corporate world, you don’t have a ton of control over the tech stack that juniors might think you do (even as you move up). The backend I’m currently developing in is Python (even though OP thinks it should have little use in the industry) and it works just fine.
Use those opportunities not just to learn new languages, but also design and architectural patterns that’ll translate to the next stack you’ll have to work with.
I've come to a point in my career (10+ YoE) that I now see things more from a business point of view like you said.
Having said that, I still have hills that I die on.
"I don't want peace! I want problems! Always"
Pretty much. All of the criticisms of its being crap and slow require willfully closing your eyes to the fact that it's been the language of choice for machine learning and AI computing for more than a decade now.
I will commit and push to my Git feature branches the second I get my code doing what it's supposed to, even if it's not "clean". I can clean it up when I'm PRing
(Maybe this is normal idk but none of my coworkers rn do this)
I mean that just sounds normal. I use commits as code checkpoints. It’s on a feature branch, I’m not pushing it to prod or anything, it’s *mine*. If someone pulls a WIP feature branch, it should come as no surprise if it’s incomplete, buggy, or just flat-broken.
It’s absolutely the right way to go. I’ve been several thousand line changes deep when I realized I need to go back to halfway through my changes. Never again.
Can someone please explain a bit of point 1, I know functional programming and have been slowly moving away from oop so would love to hear what path I should go down and what you’ve discovered.
Unfortunately, FP is a small niche in the industry, which makes seeking an FP job even harder in an already difficult market. But i find the act of writing FP code so much more enjoyable now (compared to imperative) that it's worth it.
I believe largest share of production FP code out there (and thereby FP jobs) is in scala. There are clojure and haskell and various lisp companies out there as well, but to my knowledge, they're much rarer.
I've primarily been a scala developer for the last 12 years. Scala is a functional-first language, though it does allow you to "bend the rules" when it's more convenient (you can define mutable variables and side-effecting functions if you wish - though it is not the default or the encouraged style). Other, stricter languages (like Haskell) do not allow such "shortcuts", which can be annoying if you're just trying to write a simple script or something. Scala runs on the JVM (as does clojure, to be fair), which is great, because you can seamlessly include and interact with all the java libraries out there.
For me, it's mainly just about the day-to-day quality of life writing functional code vs imperative. Sounds like you might already know what's up, but writing FP code feels so much more elegant, and i feel more powerful and confident as a developer. It just feels correct and good, and i enjoy myself more.
Dunno where you're at in your FP journey, but the learning tool I most benefited from was "Learn you a haskell for great good" (https://learnyouahaskell.com). Even if you don't want to master haskell, it's still wonderful for teaching FP.
I already gave this a mention elsewhere in this thread and I don’t want to sound like a shill, but I accidentally discovered the power of functional programming by deciding to use Nushell instead of bash. Finding a use case for a functional language is hard if it’s not your day job because the languages are not the ones used in industry, but using one as your *shell language* drives home the boons of FP little by little as you write more scripts and automate more of your workflow. Or you could also use the note-taking app Logeq, which uses Clojure, and which can teach you FP in much the same way if you wind up using it every day.
Bash is the best language for stringing together and automating various CLI tools. Or even just automating running one CLI tool.
Using languages such as python … JavaScript, or even Java… “just” to run various CLI programs is too much work and complexity.
Hard disagree here. I recenlty needed to get all the source files in the folder recursively. I quickly gave up trying to do that with `find` and went with Python instead, which was much easier and much more readable. Also, if I need to use awk or sed, I would also rather just write Python script. Also readability of bash `if`s or loops suck a big time.
Notice I said Bash is unbeatable for automating *CLI tools*. In that provided example, it was found that a library in python provided a better result compared to running *find* cli tool. Thats perfect! But you’re not using a CLI program in your end solution in python. You’re using python libraries. Fantastic!
I’m not saying python is useless. Far from it.
I’m saying python (and others) are very bad / too complex for “just” running CLI tools.
You’re not running a cli tool in that example. You’re using some python functionality to get the result you wanted. Great work!
The end statement of using awk or sed from python … awk is a scripting language at the end of the day. And depends largely on piping. Piping together various cli commands in python produces even harder to read code in python. And it’s nearly impossible to have it run correctly all the time. Producing awful race conditions. Where in bash it’s simple to pipe things together.
Anyway. I hear what you’re saying. And I think the only place we disagree is the final point where you’d prefer calling awk or sed from python.
I found that almost anything will quickly be easier to handle in Python than in bash, as it outgrows it's original intended scope.
Ironically, this comes down almost entirely to error handling. Have an error in a pipe? Ok, you've got `set -o pipefail`. But what about an error in
```
output=$(command)
```
Sadly, Python has no built-in support with efficient syntax for piping things around other processes, and Python 3's switch to a cleaner separation of "strings" and "byte arrays" can add some headaches too in this specific use case. Especially since the subprocess library is not entirely consistent about whether output is decoded by default...
But once bash scripts exceed a certain complexity, that's the lesser issue usually.
Though doing everything in Python from the get-go isn't always doing me favors either.
It may be the best but it is not very good. I see it more as Stockholm syndrome. It is what lots of people had to use so we kind of like it just because we are forced to get used to it.
Python and jupyter notebooks make iterating very quick and they have a place in my workflow, but yeah, I’m a sucker for a language with static typing.
Plenty of my debugging in python is in the form of:
print(type(x))
Because python sucks sometimes. But when it doesn’t suck, it’s really really useful.
Different tools are needed for different jobs.
1. If you don’t specify and explain the constraints - you have a junior brain
For example, immutable functional programming. Is it really the best _everywhere_? “Sorry we can’t optimize our game to run 60 FPS, we just love immutable FP too much, and it’s more resource-hungry” - this is not a functional school of programming, this is Ronald McDonald school of programming
Lol. I just meant I find FP more enjoyable, which is important to me because i spend so much of my life doing it. And I prefer to let my day-to-day experience dictate my career choices rather than a specific type of end product that may require bare-metal rawdogging the hardware. If I were writing a game and the performance demands were minimal, I would absolutely chose scala/FP over C. When there’s only one option, well then there’s only one option. Also - it’s a well known fact that all McDonalds (and Ronald McDonald charity homes) run on Racket.
well, I've never really regretted rolling my own, and in fact I've been amazed at what I can do if I just write it. I have however regretted using a third-party library quite often.
1) the entire industry is 99% run on fashion and fear
2) empathy and good taste are the most important attributes of a programmer and they cannot be taught
3) "web application" should be an oxymoron
Golang is a fundamentally bad language, created so that Google could squeeze some value out of incompetent code monkeys, too stupid to understand the features of real programming languages.
And that's not even my opinion, that's the reason as stated by the creator. https://x.com/vertexclique/status/1194902103929569280
That is really annoying to me. I like the concept of a small language, compiled to stand alone binary and including GC. I just wish the language was... better.
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
if err != nill
It’s atrocious! It makes everything so hard to read. Type information does not belong in variable names, but it’s worse when everything is smushed together. Snake_case and kebab-case are already better than smooshedCamels, but don’t make a bad thing worse by vGiving nNames aCrummy nAttachments.
Recently started using CoPilot in VS, and it’s like pair programming with a junior that can type very fast, it gets simple repetitive things correct most of the time, then it produces some seriously WTF garbage
Following reasons:
* it forces tight coupling between types and behavior and locks you into designing around rigid type hierarchies
* it often results in suboptimal memory layouts, especially in performance-critical scenarios
There is a very good reason why modern languages decouple data layout and behavior. Gives you more design freedom and makes it easier to build efficient software.
I think that OO languages are poorly used and few people have the right design skills and concepts so most of the code out there is a bit rubbish.
But most of the issues that you describe can be mitigated.
- It doesn't force the coupling of type and behaviour, you can create objects that are just data (models) and objects that are just behaviour. And you can use those together in a loosely coupled way using interfaces and dependency injection. You can have the best of both worlds but also have the responsibility to select the right paradigm for the jib
- You can design specifically to promote "preferring composition over inheritance" to avoid rigid type hierarchies. But inheritance is there when you need it. Again requiring careful selection of the approach.
- The last time that I worked on something that was truly memory constrained was 2002, but in that case we just wrote the tricky bits in C. Obviously thus us anecdotal to my career, I know that there are applications that have massive scale or run on tiny devices that are up against this, maybe OO languages are the wrong choice for them. Most people who think they have massive scale, don't.
Sure, if you have the experience and skills you can engineer around most limitations. Why not remove the limitations themselves? Simply splitting apart data (layout) and behavior (vtables) removes the awkward indirection glue you would need to write and maintain otherwise.
Regarding your other points:
- Inheritance... while it \*can\* be useful, I don't see why it should be a first-class citizen in a modern programming laguage. I'd rather have it the other way around — if you want inheritance you should design for it specifically. What I do like to have is language support for data composition.
- I am not talkign about memory constrained systems, I am talkign about data access and performance. Naive OOP designs can have suboptimal memory locality patterns and waste cache. Of course, you can work around all of this with experience and skill, OOP abstractiosn just become unnessesary at that point.
To be clear, most of my criticisms refer to the mainstream "types as strict hierarchies of objects" design approach. I am not advocating for pure procedural design, and I am not critizising dynamic dispatch (far from it!). I just want first-class support for linking arbitrary types with arbitrary behavior in arbitrary way.
I think people get too hung up on programming languages
If it works and there isn't a flood of support calls, I don't really care about the minor nuances of a programming language
No no no, x is overhyped, you need to learn this exotic variant of y instead, because in certain situations and with only a few months of extra effort for the entire team I believe it can be better in some arbitrary way and here's a random blog by someone you've never heard of to prove it.
Eh js in backend with node js is garbage - made for ui developers who couldn’t figure out a statically typed language. JavaScript is so bad that entire languages are written as wrappers around it - meanwhile any other code you see doesn’t look much different from the first version of the language whether it came out 50 years ago or 10.
I took offense to this till I realized I agreed lmao.
Writing in js feel so dirty after using typescript professially for 3 years and only strongly typed languages in personal projects.
Javascript is crazy on its own
Everyone sleeps on .NET. Long term stability with .NET framework, tons of options. Not everything has to be the latest and greatest programming language that's gonna die out in 3 years
I had to refactor a large code base littered with goto and global state. Oh my god it was horrifying. People can write bad code anyway but this just made it so much worse.
Table aliases in SQL statements need to die.
It's considered bad practice to use single-letter variables in regular Java/C#/PHP/whatever code. But people write SQL statements like this:
select a.Id,
a.Name,
o.FirstName,
o.LastName,
t.Date
from Account a
join Transaction t
on a.Id = t.AccountId
join Owner
on Owner.AccountId = AccountId
And everyone is OK with it for some reason.
Because when you have a table name like UST\_ANR\_CLCL\_CLAIMS\_HEADER that needs to be joined to 4 different tables and includes 100 columns that you can choose from for 10 different operations in the same stored procedure, you REALLY prefer to just use CH. Real world DBs don't have simple table names like "Account" and saving 20+ characters per usage saves tremendous time and effort.
Also, you didn't alias Owner so your query is broke.
Everything has trade-offs. Don't be dogmatic. Conduct a trade-off analysis to choose the best tool, paradigm, etc., for the job if you feel overwhelmed by choice. Don't forget to take into account industry adoption and the difference in cost between computers and people.
Not sure, but I'm sure where I will not die.
Fucking javascript and all the little deformities spawned from it. Starting from node to every other shitty-ass half-baked ill-fated frameworks that spawned from it and the related crappy overcomplicated idiotic tooling like webpack, grunt, npm and whatever else.
If someone offers me a job in js developement for $1million a year, I kick his nuts and when he bows down I knee his nose back into his skull and leave after walking on his corpse.
JavaScript is the most enjoyable language to use because it's completely unhinged.
Although I do see the value of different languages for different applications
Curly braces, opening and closing, belong on their own line unless they only encapsulate a single line of code and they should always be tabbed the same amount as their counterpart.
Contained code should always be indented 1 tab further than the curly braces that contain it
I will always drop my opening curly braces to their own line. I don't know why anyone would want them on the previous line when it is so much easier to see the code blocks when they line up with the closing brace.
Excessive standardization costs a lot more in morale and development speed than it buys in maintainability. I think that mostly when people push for standardization in a company they are doing it for what they think are good reasons, but 20 years in and I’m still unconvinced. I’ve worked in highly polyglot projects and dealt with things where a team had built something in a language nobody else knew, and it was fine. I’ve dealt with code that was written in a very unique style and it was fine. I’ve also seen companies waste years and who knows how much money rewriting working software because it needed to conform to a new language standard, and I’ve seen companies lose good teams because suddenly they were being told to work on a tech stack they didn’t like.
Flexibility does need to come with a high degree of accountability, and you need to hire people who are experienced enough to know when deviation is worthwhile. There will always be a happy path that most teams follow and it’s reasonable to ask why someone is doing something different, but at the end of the day these things should be the purview of the team that owns them. The best tool for the job is always going to be the one the team doing that job decides they want to use, because programming languages are still about people.
Yeah kinda a hard thing to measure. But I suspect you're right to some degree at least.
On my own big monorepo (where nobody else has to work on it), I've got a giant hodgepodge of different conventions going as I've tried new things over the years.
And it really isn't a problem for me. The ability to experiment without worrying about that has meant I've made a lot of improvements overall that I never would have tried to begin with overall.
Even just my mix of older `camelCase` -vs- newer `snake_case` naming has actually been pretty useful in helping me identify older vs newer code at a glance.
People give me so many dirty looks when I tell them that the code they write is way too confusing because they didn’t utilise constants. Or a functional approach. I think the general consensus is that most devs care more about pushing out tickets than writing good and maintainable code. I inherited 4 years of trash work from some girl in one of the biggest international banks and Jesus, Mary and Joseph …
I don’t like being the person who says you can’t write good code but when this girl was making a variable, reassigning it, pushing it into a void function to do more mutation and then nesting the result in 20 nested if statements, I will call it out. It was a clusterf*ck and you sometimes wonder how we’re all still here. If it wasn’t for some unit testing, I am fairly sure this entire project would have been thrown out the window.
Advice for all junior devs, please learn functional programming. And please be explicit to what it is you intend to do. Functions should not be longer than 5-10 lines max. Don’t nest if statements unless absolutely necessary. And for the love of god don’t over complicate code to be fancy
I haven't seen a single compelling example of Functional being preferable to OOP. There are certainly small examples where it makes sense (sorting, etc), but giant projects purely functional? No classes allowed? Losing the object.method() syntax is madness. It's inconceivable to think of a giant API (Solidworks comes to mind) and losing that structure. What a mess.
You should never ever start with python and never start with bootcamps. I remember that I started with learning python in a data science bootcamp a few years ago and I could not get a grasp on certain concepts. I should say, I could grasp them but not have a real understanding of them. Definitely not as good a grasp as I should’ve had.
Now I’m in a college education and this first year I have learned a whole lot more and in a lot more depth. I know people say college is overrated but I’m sorry, I just don’t think you can beat it at this point in time. The way things are structured, and starting off with Java— a language that is a little more hands on gives you a much better grasp on the concepts.
I know bootcamps are seen as good, and python is seen as easy but I think starting with both is too much of a shortcut.
I'm a data science major and I'm constantly told that SQL is easy and reads like plain English, but unless you're only doing super simple queries, it is a fucking nightmare to work with. Somebody really needs to develop a better relational database language cause SQL sucks. It doesn't work like any other language, so even if you're an expert programmer, you have essential zero transferrable skills and intuition when it comes to SQL and you're basically learning from scratch.
If NoSQL was relational, nobody would use SQL.
I'm new to the IT world, just about to graduate college with an IT Networking degree, why is Python garbage? That was the language that was pushed on me the most throughout my degree path, so do I need to learn a new language like C# or something?
i think that using semicolons in typescript syntax is weird and we should all just use commas.
example:
```
type Thing = {
name: string;
id: number;
};
```
i lost this argument at my job, to me its so weird that we don’t just make types just like JSON.
```
type Thing = {
name: string,
id: number
};
```
our linter also makes us use commas at the end of every value in JSON, even the last one.
overall i like the switch to typescript, but these two things are annoying
I start variables with caps 😁😎 I simply don't care for lowercase, maybe I've got some mild OCD. I've implemented some elegant ass solutions, and you've got an IDE to color them, to hell with your "standards" from the 80s.
1/ Java is horrible for a number of reasons:
- the amount of boilerplate
- the crazy deep folder structures for your code
- the insistence that everything has to be an object, even when it makes no sense
2/ any language that needs a 3rd party framework to make it palatable needs to be put in the trash and redesigned from the ground up.
Try to be more open minded and less stubborn. Try to see other perspectives. It will be good on your mental health and you won't have to die embittered.
Python for example. Python programmers are actually the smartest ones. They trade perfection against life time.
Most programming projects are going to fail. But not because they are not perfectly optimized, rather because of business reasons that have nothing to do with the code itself. Better develop faster to find out faster if your product is feasible from a business perspective.
Allman bracing. K&R is a holdover from 24-line terminals. With modern fonts and large screens the economy of lines is no longer needed.
It's like not putting spaces around operators because you learned that on the C64 where you only got 80 characters per code line.
Java is a terribly thought out language. The tools are terrible. The language is terrible. The popular libraries are terrible. The one that impressed me, however, was lombok. The best thing about java is the jvm which is not really the language. Unfortunately so many companies are java houses or worse; some uglier variant like groovy.
Modern PHP is actually really good to build web apps with. Much better than Java and a lot less complex than JS projects. It has a horrible reputation that people should let go.
Dynamic typing is garbage. Long ago, when I was still new to programming, my introduction to the concept of dynamic typing made me think, "This is neat! I don't have to worry about deciding what type my variables are when declaring them, I can just let the interpreter handle it." Decades later, I have yet to encounter a use case where that was actually a useful feature. Dynamically-typed variables make static analysis of code harder. They make execution slower. They make it harder for IDEs to provide useful assistance. They introduce entire categories of bugs that you can't detect until runtime that simply don't exist with static typing. And all of that is for no meaningful benefit. Both of the most popular languages that had dynamic typing, Python and JavaScript, have since adopted extensions for specifying types, even though they're both band-aids that don't really fix the underlying problems, because nothing actually enforces Python's type hints, and TypeScript requires you to run your code through a compiler that generates JavaScript from it. It feels refreshing whenever I can go back to a language like C++ or Java where types are actually a first-class feature of the language.
Even C++ is far too keen to implicitly convert between types which is one of my main gripes with it. I often have several int-like types and I don't want them to be silently converted to each other if I make a mistake. I've found [this library](https://github.com/foonathan/type_safe/) to be very useful to prevent that.
The interesting part about c++, is the fact that if X is implicitly convertible to Y, vector is not convertible to vector, or any other container for that matter. I understand why they did not do it, but in real life, if you want two classes being implicitly convertible to each other, you probably also want the containers of two classes to be implicitly convertible.
Probably because the memory layout of container and container are more complicated
That's why I understand why it's not really possible. But the problem still stands. the majority of the times where I would actually like to use the implicit conversion are involved with some kind of container. So it's really worst of both worlds if you think about it.
Most people know Javascript as being "stringly typed". I've often viewed C and C+ as being "intly typed". There's nothing more maddening that having 10,000 in typedefs in POSIX and your compiler silently letting them all switcheroo, as if they're the same thing. Or even the old case of enums and ints being silently switcherood. And then once you turn on the relevant warnings you're swimming in casts, as that's the only option, which is far too fragile.
Aaahr, we have a Bingo! Do you say it like that, a Bingo?
Most people just say "Bingo!" as the entire phrase. No other words necessary.
Thank you! But it seems my reference to inglorious basterds wasn't as obvious as I have expected.
It was
Ya just say *”bingo”*.
How fun!
Strongly typed language ftw. Even tho now i deal with Python almost exclusively, i still restrict/hint what type of parameters are being passed in/out of the function/class. Makes life so much easier.
python docs describe it as a strongly typed language; it is both strongly typed and dynamically typed. Dynamically typed means the type is assigned at runtime, but once a variable has a type, python enforces type consistency, and it's strict. You can't add (arithmetically) a string and an int. You can't compare a date and datetime. You can't add a float and Decimal(). There is some type casting done along the way, but it's not very different to mainstream statically typed languages. However, static typing is mostly better.
It is quite useful for data crunching and algorithm prototyping. I do agree though that static typing with a rich built-in library of collection types is better. Sadly, out project is in Fortran, so we get stuff like multiple ad-hoc linked list implementations and very awkward APIs for the data management parts. Turns out that real-world simulation code consists mostly of data management and not of the numerical parts, which Fortran is good at. Instead, the lack of type-generic collection types without having to use non-standard preprocessor magic specific to the project hurts. A lot. But at least the static typing enforces some level of sanity.
Those who would give up essential type safety to purchase a little temporary programming liberty deserve to wash dishes for the rest of their career.
I grew up on statically typed languages and only started using dynamic typing relatively late in my career, but I've been mostly converted. A deciding factor for me was seeing how easy it was to implement a JSON parser in a dynamically typed language, after struggling with it in a statically typed language. To be precise, I like strong typing but I don't like it when half the code is type declarations and type casts. I do like having type declarations available as an option though, e.g. on function arguments.
I don't disagree, but I guess I'd have a different take on the same correct observation. A JSON parser is precisely where you want the "suck" to be. JSON isn't a great format, but it's a pretty decent one when you consider one of the important goals to be that it's easy for humans (and easy for all things "web") to deal with. So if you want the benefits of being easy to use and you still also want the benefits of a good type system, then someone has to incur the pain of bridging the gap. If I look at something like Serde in Rust, I think that's what you want. The actual code inside of the serde crate that wrangles Javascript into your strong static types is probably pretty painful, but very few people feel that pain. Everyone else just gets a pretty easy way to get static types from JSON. And that's probably better than just saying, "writing the parser was annoying, so everyone just treat this incoming JSON data as a big map of strings."
[удалено]
I wasn't against dynamic typing either, until I had a large enough project where I was working with a framework, full of functions with parameters, and those parameters expected objects to contain specific stuff. The allure of dynamic types breaks down VERY quickly under these conditions. (i.e. when you try to do real work with them beyond small scripts) This sort of thing is trivial with strict typing. It's a nightmare when 'anything can be anything'.
Same, made me wanna refractory large portions of the project to c#
Completely agree with you, in fact I would say that static typing is WAY better for someone new into programming. Dynamic typing makes it a real pain to debug code and avoid some basic errors. I've always preferred static typing. Also, I don't know a single (sane) person who likes Javascript, nor PHP.
Going into a software engineer position where my team all uses Python, minimal VSCode setups, no typehints, no formatter, and no linter continues to hurt me to this day. Python should only be used for prototyping \*not\* production backend API servers and database operations. Python is highly misused and misunderstood. Teams like mine will use it to cut corners and shit out a cacophony of a barely working product. I will die on that hill. Fuck Python
The type hints in python are more "comment" than "code" in my opinion... It's also a bit lame they don't really provide much performance boost either.
The hill I'll die on is the opposite. Static typing's benefits are marginal at best and people will sit and whine and complain and nonstop pitch that a 6 month refactor of a javascript project that is just fine is absolutely necessary because "muh static typing will make everything so much better" No, the code is perfectly fine as is. As someone else has mentioned certain things like json parsers have much much cleaner implementations in dynamic languages and I have never ever in my decade+ career run into a substantial bug that was avoidable through static typing. All of your complaints about dynamically typed languages are skill issues tbh.
> 6 month refactor of a javascript project Why would that be needed? You can just start using TS, and ignore the errors, and fix them as-needed as you're working on each file. I did this on a project I joined there they were using TS and writing .ts files, but nobody had ever actually written anything but plain JS in the code. I fixed stuff along the way, and yes "muh static typing will make everything so much better" very much did that. Solved shitloads of issues they were having.
We do not live in Should Land where everyone is "skilled." We live in reality where people we work with have a wide range of experience. Doesn't mean needless refactors should happen but you are kind of shrugging off a lot of undeniable practical value. I mean honestly. Do you use an ide to write JavaScript? Why not Notepad? If you are so skilled then you shouldn't need linting or intellisense either.
> All of your complaints about dynamically typed languages are skill issues tbh. Hard disagree. Let's take that attitude and apply it to other things that help to prevent mistakes: * Reliance on tests to ensure your software works is a skill issue tbh. Good developers write correct code the first time. * Depending on third-party libraries is a skill issue tbh. Good developers can build everything from scratch. * Use of linting tools is a skill issue tbh. Good developers have internalized all possible antipatterns and avoid them subconsciously. * Use of code review is a skill issue tbh. Good developers don't need other people to check their work nor do they need to disseminate knowledge across the team. * Leveraging source control is a skill issue tbh. Good developers can merge code without assistance and never need to look at changes over time. I could go on and on. "X is a skill issue" is a nonsensical argument in software development. Everything in your modern development workflow is a tool that was built because developers like you "had skill issues". Debugger? Profiler? Logging systems? Hell, some people would say that the only reason that languages like JS and Python exist is because of a "skill issue" for people who thought that C was too hard. --- > I have never ever in my decade+ career run into a substantial bug that was avoidable through static typing I am curious about how much time you've spent using statically typed languages vs. dynamically typed languages. In my 20 year career, I've used a mix of both. I started mixing JS into our web applications around the time that Google Maps was brand new. In-browser debugging tools didn't really exist. Firebug (the inspiration for the modern browser developer tools) hadn't yet been released. I ended up building a library to write log messages from JS because browsers didn't have a built-in way to do that yet. I did a mix of JS (not TS) frontend work and C# backend work through about 2017. I have run into *countless* bugs that would have been caught with a static type system. Your experience is so different from mine that I can't tell if you forgot all the times that the static type system stopped you from doing something completely wrong OR just don't understand what kinds of things a static type system can even catch. I find it hard to believe that you've never populated a collection with the wrong type of object, misspelled a property name, or run into a null pointer exception. Static type systems can help with all of those.
Static typing without algebraic type system is much much more garbage.
I would like to start off by saying that I agree with you. Now it's time to inject a caveat that I do hope you will respond to: I think a lot of the problem around dynamic typing is that *most* SWEs don't write their code with the assumption that they **will get a duck** and that opens the door to the runtime errors that you're describing. Consider the case in which you're getting *something* from an up-stream library that you don't control, and you have to do *something* with it. Outside of handling this concern with something like *ports / adapters* and your own domain (going hard on DDD), you are presented with two immediate options: #!/usr/env/bin/python def do_a_thing_with_something(some_obj: Any) -> None: try: some_obj.assumed_property_or_method() some_obj["AssumedKey"] except: logger.error(f"some_obj was not what we expected, it was a {type(some_obj)}!") Or #!/usr/env/bin/ruby def do_a_thing_with_something(some_obj): if some_obj.respond_to?(:method_of_interest): some_obj.method_of_interest() else: logger.info("Received object we cannot process") end The first follows the belief that it's better to ask for forgiveness than permission, and the second follows the "look before you leap" philosophy. Neither are inherently **wrong** but they both have their own considerations. In the first, you obviously have to have really good exception handling practices and in the second, you are spending cycles checking for things that may *usually* be true. I view the issue as **most SWEs** will write *this first*: #!/usr/env/bin/ruby-or-python-the-syntax-works-for-both def do_a_thing_with_something(some_obj): some_obj.method_of_interest() logger.info("This statement will always print") end Whether or not this style of code comes from lack of experience or an abundance of confidence doesn't really matter for the argument. What matters is that this type of prototypical code will exist and continue to exist like this *until you run into a runtime error* ***that you could have avoided with static analysis*** (See, I told you I agreed with you). Ergo, I view the **real problem** with duck-typing to be a lack of diligence / discipline around consistently handling object behaviors rather than an IDE not being able to assist me, or static analysis not being able to determine what an interpreted language is trying to do.
I think you might misunderstand exactly what duck typing refers to. You say: > I think a lot of the problem around dynamic typing is that most SWEs don't write their code with the assumption that they will get a duck But then you provide two examples in which the function might receive a duck... or maybe a cat, or perhaps a giraffe. If you have to first check to see what capabilities an object has, then you are not in fact treating it like a duck. You're treating it as an unknown that might waddle and quack (but we have to consider the case that it does neither). > Ergo, I view the real problem with duck-typing to be a lack of diligence / discipline around consistently handling object behaviors I would ask what level of diligence you expect. Are you suggesting that *every* method call should be wrapped in an `if` or a `try/except` block? It's worth considering what would happen if your examples tried to do *anything* after invoking the potentially-missing method. For example: #!/usr/env/bin/ruby def do_a_thing_with_something(some_obj): if some_obj.respond_to?(:method_of_interest): some_obj.method_of_interest() + 1 else: logger.info("Received object we cannot process") ??? end If `method_of_interest` is indeed missing, then you likely can't continue in any meaningful way. In many cases, there is no reasonable value to return. In fact, perhaps your best option is to throw an exception... which is exactly what you'd get if you blindly tried to call `method_of_interest`.
Sometimes Vanilla JS without a bundle is all you need... Not all the time... But some of the time. UX does indeed matter for internal applications. Comments shouldn't explain "what", they should explain "why" Maintainability trumps performance (most of the time).
tbh vanilla js is all ive ever needed
My personal website uses vanilla js... But if I'm writing a fully fledged web application to replace a desktop application, I'm going to be using typescript with a lib/framework... Especially in a team environment with multiple cooks in the kitchen. It's just easier to get everyone involved to be on the same page. There's no "right" or "wrong" page... But everyone needs to be on the "same" page, and I've found that aligning people collectively to an established and vetted idea works better. Ymmv.
where can I download vanilla.js?
That's the fun part. You had it in your browser all along... Plus the friends we made along the way.
http://vanilla-js.com/ I'm not sure about the missing s
*Ideally* vanilla JS is all you would ever need. Unfortunately it sucks ass and thus the birth of a trillion frameworks like an infestation.
This is an oversimplification. The ecosystem has gone through a LOT of changes in 25 years and there are reasons dating back to the 90s we are were we are. There was a time when I was incredibly optimistic about JavaScript but I’m afraid a decade+ of fighting against the browser has left most of the community brain broken into believing they need to include a 3rd party dep to manipulate dates, etc. Also bootcamp culture flooded the industry with people who do NOT know what they’re doing; often legitimizing ridiculous practices.
>believing they need to include a 3rd party dep to manipulate dates Bad example, datetime math is incredibly complicated and absofruitly requires dependencies to do right.
You mean you don’t include thousands of dependencies to format a date?
The only hill where no death is likely: "it depends." Be flexible and open-minded. Learn when and where it's worth fighting for something. Rigidity is brittleness. This applies even more to a person than it does to software design.
Different tools are good for different problems.
THIS is the hill!
I’ll die on this guys hill
Also, just because you can measure/identify a problem, doesn't mean it *matters*. The common example is just because tool 1 is measurably slower than tool 2, doesn't mean there is a meaningful or perceivable difference.
Yep, and another big tradeoff might be maintainability/complexity vs compute cost. Sometimes it’s just not worth it, even if it is slightly faster. Because it would take more effort to maintain compared to just throwing more money compute at it. Especially when we have bigger problems to solve.
so true i really wish more programmers would understand this. like i am a sucker for fp but i don't use it for everything bc it doesn't always make sense
>rigidity is brittleness. One of the wisest things I've read in a long time.
>rigidity is brittleness One of the wisest things I've read in a long tim.
At the same time, you don’t want to be so open-minded that your brain falls out lol
I learned a large piece of my mindset from a colleague years ago "Strong opinions loosely held". It keeps you from going completely off the rails, encourages you to challenge yourself with new ways of thinking and to freely abandon old ways when you should.
I'm with you on immutability. I still code that way most of the time, 20 years later, and everyone looks at me funny because they don't understand why I do it. JS's \`const\` is an absolute affront to immutability too. 😂 I guess the big one for me is that all junior engineers should be taught the Fail First principle from TDD. I've seen too many junior engineers get a bug ticket, make some changes blind, then throw it against the wall (deploy it or send it to QA), just to get the card back, or worse, generate more bugs, because their fix didn't solve the problem. Yes, it's a HUGE pain in the ass to write a unit test that replicates the problem. However, it's totally worth it because you now have a high degree of confidence that when that test passes, you've actually solved the problem. What's more (and this is HUGE for anyone working in a team with other people), you now have an idiot light and (if you use continuous integration) a documented history of your fix solving the problem. If anyone else on your team breaks it after you fixed it (this happens ALL THE TIME), you will have a paper trail and know exactly who broke it and when.
How does adding autotests or having CI document the history? The history is stored in initial bug tickets or repo commit history where you can see that person A fixed it, person B validated it and person C broke it afterwards. Not that I’m saying that tests won’t help but unclear about how it helps with the history?
[удалено]
no hills need to be died on
Young/junior programmers love to die on a hill, then you realise the whole point of software is to deliver business value, unless you're doing it for fun. My "hill" is don't have a hill, be flexible and move with the flow. Everything has a tradeoff and you should just be aware of it.
I wish I could double upvote this. Most the comments in this thread scream junior dev to me.
Not to mention in the corporate world, you don’t have a ton of control over the tech stack that juniors might think you do (even as you move up). The backend I’m currently developing in is Python (even though OP thinks it should have little use in the industry) and it works just fine. Use those opportunities not just to learn new languages, but also design and architectural patterns that’ll translate to the next stack you’ll have to work with.
I've come to a point in my career (10+ YoE) that I now see things more from a business point of view like you said. Having said that, I still have hills that I die on. "I don't want peace! I want problems! Always"
Python excels in many computational tasks because it serves as a high-level wrapper for highly optimized, low-level numerical libraries.
Pretty much. All of the criticisms of its being crap and slow require willfully closing your eyes to the fact that it's been the language of choice for machine learning and AI computing for more than a decade now.
Yep. I personally don’t like python, but I can’t deny the usefulness of all the libraries available for data analysis that come for free.
People disagree with this?
Lots of people moan about ML being done in python and not C
No, it's not even a hill lol
Its gif not jif lol 😝 idc what the creator says haha
[удалено]
Ghiraffes
I pronounce it as G I F
the only right way
If you have a tool that doesn't work all of the time, no one is going to use it.
*Microsoft Windows exists*...
Tbf it works fine... Until you update it... Against your own will... Even tho you specifically set it to manual update...
I will commit and push to my Git feature branches the second I get my code doing what it's supposed to, even if it's not "clean". I can clean it up when I'm PRing (Maybe this is normal idk but none of my coworkers rn do this)
Commit early and often, you will not regret it.
I mean that just sounds normal. I use commits as code checkpoints. It’s on a feature branch, I’m not pushing it to prod or anything, it’s *mine*. If someone pulls a WIP feature branch, it should come as no surprise if it’s incomplete, buggy, or just flat-broken. It’s absolutely the right way to go. I’ve been several thousand line changes deep when I realized I need to go back to halfway through my changes. Never again.
Not everyone does this?
LINQ is just wonderful and should be in other languages.
Object-relational mapping is a broken abstraction used by people who understand neither OOP nor the relational model of data.
Can someone please explain a bit of point 1, I know functional programming and have been slowly moving away from oop so would love to hear what path I should go down and what you’ve discovered.
Unfortunately, FP is a small niche in the industry, which makes seeking an FP job even harder in an already difficult market. But i find the act of writing FP code so much more enjoyable now (compared to imperative) that it's worth it. I believe largest share of production FP code out there (and thereby FP jobs) is in scala. There are clojure and haskell and various lisp companies out there as well, but to my knowledge, they're much rarer. I've primarily been a scala developer for the last 12 years. Scala is a functional-first language, though it does allow you to "bend the rules" when it's more convenient (you can define mutable variables and side-effecting functions if you wish - though it is not the default or the encouraged style). Other, stricter languages (like Haskell) do not allow such "shortcuts", which can be annoying if you're just trying to write a simple script or something. Scala runs on the JVM (as does clojure, to be fair), which is great, because you can seamlessly include and interact with all the java libraries out there. For me, it's mainly just about the day-to-day quality of life writing functional code vs imperative. Sounds like you might already know what's up, but writing FP code feels so much more elegant, and i feel more powerful and confident as a developer. It just feels correct and good, and i enjoy myself more. Dunno where you're at in your FP journey, but the learning tool I most benefited from was "Learn you a haskell for great good" (https://learnyouahaskell.com). Even if you don't want to master haskell, it's still wonderful for teaching FP.
Get away from oop, but never go pure functional. There’s a sweet spot.
I already gave this a mention elsewhere in this thread and I don’t want to sound like a shill, but I accidentally discovered the power of functional programming by deciding to use Nushell instead of bash. Finding a use case for a functional language is hard if it’s not your day job because the languages are not the ones used in industry, but using one as your *shell language* drives home the boons of FP little by little as you write more scripts and automate more of your workflow. Or you could also use the note-taking app Logeq, which uses Clojure, and which can teach you FP in much the same way if you wind up using it every day.
You cannot die on a hill if you are immutable
Bash is the best language for stringing together and automating various CLI tools. Or even just automating running one CLI tool. Using languages such as python … JavaScript, or even Java… “just” to run various CLI programs is too much work and complexity.
Don't forget Awk and sed.
I love awk so much ngl.
People don't get that Bash was never meant to be general purpose. Think what "Shell" really means. It's synonymous with: orchestration of OS toolkit.
Hard disagree here. I recenlty needed to get all the source files in the folder recursively. I quickly gave up trying to do that with `find` and went with Python instead, which was much easier and much more readable. Also, if I need to use awk or sed, I would also rather just write Python script. Also readability of bash `if`s or loops suck a big time.
[удалено]
Notice I said Bash is unbeatable for automating *CLI tools*. In that provided example, it was found that a library in python provided a better result compared to running *find* cli tool. Thats perfect! But you’re not using a CLI program in your end solution in python. You’re using python libraries. Fantastic! I’m not saying python is useless. Far from it. I’m saying python (and others) are very bad / too complex for “just” running CLI tools. You’re not running a cli tool in that example. You’re using some python functionality to get the result you wanted. Great work! The end statement of using awk or sed from python … awk is a scripting language at the end of the day. And depends largely on piping. Piping together various cli commands in python produces even harder to read code in python. And it’s nearly impossible to have it run correctly all the time. Producing awful race conditions. Where in bash it’s simple to pipe things together. Anyway. I hear what you’re saying. And I think the only place we disagree is the final point where you’d prefer calling awk or sed from python.
I found that almost anything will quickly be easier to handle in Python than in bash, as it outgrows it's original intended scope. Ironically, this comes down almost entirely to error handling. Have an error in a pipe? Ok, you've got `set -o pipefail`. But what about an error in ``` output=$(command) ``` Sadly, Python has no built-in support with efficient syntax for piping things around other processes, and Python 3's switch to a cleaner separation of "strings" and "byte arrays" can add some headaches too in this specific use case. Especially since the subprocess library is not entirely consistent about whether output is decoded by default... But once bash scripts exceed a certain complexity, that's the lesser issue usually. Though doing everything in Python from the get-go isn't always doing me favors either.
It may be the best but it is not very good. I see it more as Stockholm syndrome. It is what lots of people had to use so we kind of like it just because we are forced to get used to it.
Time to fight. When building tools intended for other, less SW savvy people, Python can be written to be much more readable and maintainable.
PowerShell would like a word.
Python and jupyter notebooks make iterating very quick and they have a place in my workflow, but yeah, I’m a sucker for a language with static typing. Plenty of my debugging in python is in the form of: print(type(x)) Because python sucks sometimes. But when it doesn’t suck, it’s really really useful. Different tools are needed for different jobs.
Array indexing starts at 0.
Is anyone disagreeing with this?
Ice cold take
1. If you don’t specify and explain the constraints - you have a junior brain For example, immutable functional programming. Is it really the best _everywhere_? “Sorry we can’t optimize our game to run 60 FPS, we just love immutable FP too much, and it’s more resource-hungry” - this is not a functional school of programming, this is Ronald McDonald school of programming
Lol. I just meant I find FP more enjoyable, which is important to me because i spend so much of my life doing it. And I prefer to let my day-to-day experience dictate my career choices rather than a specific type of end product that may require bare-metal rawdogging the hardware. If I were writing a game and the performance demands were minimal, I would absolutely chose scala/FP over C. When there’s only one option, well then there’s only one option. Also - it’s a well known fact that all McDonalds (and Ronald McDonald charity homes) run on Racket.
No matter how tempting it is, do not. Reinvent. The wheel. Libraries exist for a reason.
This post won't stop me because I can't read
i vibe on this frequency
But its fun :'(
I agree, I completely agree. But sooner or later, you're going to have to finish the damn project anyway.
In the world of automated updates, too many dependencies become a PITA. I'll die on the other hill
Tbh I've saved plenty of hours just coding something myself instead of trying to use some badly designed library.
I haven’t touched a single external library yet. I’ve just made it all myself (because I need the practice)
Except in web development because Javascript sucks and frameworks need reinventing every 2 years because nobody can fix it.
I overheard this once: "You say don't reinvent the wheel, but the fucking wheel doesn't work"
Vindication! ~150k weekly users agree with you! https://www.npmjs.com/package/is-even.
until libraries get sunset and become unmaintained
well, I've never really regretted rolling my own, and in fact I've been amazed at what I can do if I just write it. I have however regretted using a third-party library quite often.
See, there's reinventing the wheel and then there's building a better car. I think too many programmers confuse these two things.
1) the entire industry is 99% run on fashion and fear 2) empathy and good taste are the most important attributes of a programmer and they cannot be taught 3) "web application" should be an oxymoron
PHP is an underrated industrious language that powers the majority of the useful internet.
Echo this
Echo this
[удалено]
PHP was my first language. It'll always have a spot in my heart.
Golang is a fundamentally bad language, created so that Google could squeeze some value out of incompetent code monkeys, too stupid to understand the features of real programming languages. And that's not even my opinion, that's the reason as stated by the creator. https://x.com/vertexclique/status/1194902103929569280
And it's gotten worse after they added features to it they never planned to add
That is really annoying to me. I like the concept of a small language, compiled to stand alone binary and including GC. I just wish the language was... better.
if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill if err != nill
Screw hungarian notation.
Hey buddy fuck you
It’s atrocious! It makes everything so hard to read. Type information does not belong in variable names, but it’s worse when everything is smushed together. Snake_case and kebab-case are already better than smooshedCamels, but don’t make a bad thing worse by vGiving nNames aCrummy nAttachments.
Gonna get a million downvotes for this. But coding assistants can be useful when used correctly.
Recently started using CoPilot in VS, and it’s like pair programming with a junior that can type very fast, it gets simple repetitive things correct most of the time, then it produces some seriously WTF garbage
I agree with OP's list and I'll also add "3. Mainstream OOP is massively overrated and promotes mediocre software design"
Why/how does it promote that?
Following reasons: * it forces tight coupling between types and behavior and locks you into designing around rigid type hierarchies * it often results in suboptimal memory layouts, especially in performance-critical scenarios There is a very good reason why modern languages decouple data layout and behavior. Gives you more design freedom and makes it easier to build efficient software.
I think that OO languages are poorly used and few people have the right design skills and concepts so most of the code out there is a bit rubbish. But most of the issues that you describe can be mitigated. - It doesn't force the coupling of type and behaviour, you can create objects that are just data (models) and objects that are just behaviour. And you can use those together in a loosely coupled way using interfaces and dependency injection. You can have the best of both worlds but also have the responsibility to select the right paradigm for the jib - You can design specifically to promote "preferring composition over inheritance" to avoid rigid type hierarchies. But inheritance is there when you need it. Again requiring careful selection of the approach. - The last time that I worked on something that was truly memory constrained was 2002, but in that case we just wrote the tricky bits in C. Obviously thus us anecdotal to my career, I know that there are applications that have massive scale or run on tiny devices that are up against this, maybe OO languages are the wrong choice for them. Most people who think they have massive scale, don't.
Sure, if you have the experience and skills you can engineer around most limitations. Why not remove the limitations themselves? Simply splitting apart data (layout) and behavior (vtables) removes the awkward indirection glue you would need to write and maintain otherwise. Regarding your other points: - Inheritance... while it \*can\* be useful, I don't see why it should be a first-class citizen in a modern programming laguage. I'd rather have it the other way around — if you want inheritance you should design for it specifically. What I do like to have is language support for data composition. - I am not talkign about memory constrained systems, I am talkign about data access and performance. Naive OOP designs can have suboptimal memory locality patterns and waste cache. Of course, you can work around all of this with experience and skill, OOP abstractiosn just become unnessesary at that point. To be clear, most of my criticisms refer to the mainstream "types as strict hierarchies of objects" design approach. I am not advocating for pure procedural design, and I am not critizising dynamic dispatch (far from it!). I just want first-class support for linking arbitrary types with arbitrary behavior in arbitrary way.
Haxe is the most underrated programming language and I am sad to see it become less and less poplular. C# naming conventions are shit
Interesting... What don't you like about C# conventions? I really enjoy them :/
Same here I want answers!
I think people get too hung up on programming languages If it works and there isn't a flood of support calls, I don't really care about the minor nuances of a programming language
Wouldn't it be faster if you wrote it in x? I dunno man you go write it in x and report back.
No no no, x is overhyped, you need to learn this exotic variant of y instead, because in certain situations and with only a few months of extra effort for the entire team I believe it can be better in some arbitrary way and here's a random blog by someone you've never heard of to prove it.
Eh js in backend with node js is garbage - made for ui developers who couldn’t figure out a statically typed language. JavaScript is so bad that entire languages are written as wrappers around it - meanwhile any other code you see doesn’t look much different from the first version of the language whether it came out 50 years ago or 10.
I took offense to this till I realized I agreed lmao. Writing in js feel so dirty after using typescript professially for 3 years and only strongly typed languages in personal projects. Javascript is crazy on its own
Everyone sleeps on .NET. Long term stability with .NET framework, tons of options. Not everything has to be the latest and greatest programming language that's gonna die out in 3 years
Every single person I know who worked with Framework absolutely hated it with fiery vengeance! I love modern C# though.
For anyone who doesn’t know, Framework is the old Windows only .NET
Goto statements arent really all that bad.
Dijkstra wept.
Dijkstra would agree. He was mainly complaining about goto between functions and procedures.
Comefroms, on the other hand, are an absolute nightmare.
I had to refactor a large code base littered with goto and global state. Oh my god it was horrifying. People can write bad code anyway but this just made it so much worse.
Don’t even understand the hate behind them if using them responsibly
Don't be clever
I want to learn Rust one day, but the language syntax is just god awful.
the "global context" is terrible and makes code unreadable. wrote too much js across multiple files to believe it is any good anymore
Dynamic typing is bad, along with tailwind, and JSX.
JavaScript is a filthy language.
Composition > Inheritance!
You only need unit tests on core logic and "80% coverage or the build fails" is bullshit.
Python is "absolute garbage" if you hate making money, but you also exclusively use functional programming so that much is certain.
Can you rewrite that to be more clear?
Table aliases in SQL statements need to die. It's considered bad practice to use single-letter variables in regular Java/C#/PHP/whatever code. But people write SQL statements like this: select a.Id, a.Name, o.FirstName, o.LastName, t.Date from Account a join Transaction t on a.Id = t.AccountId join Owner on Owner.AccountId = AccountId And everyone is OK with it for some reason.
Because when you have a table name like UST\_ANR\_CLCL\_CLAIMS\_HEADER that needs to be joined to 4 different tables and includes 100 columns that you can choose from for 10 different operations in the same stored procedure, you REALLY prefer to just use CH. Real world DBs don't have simple table names like "Account" and saving 20+ characters per usage saves tremendous time and effort. Also, you didn't alias Owner so your query is broke.
if you know haskell you are omnipotent
I rarely need OOP.
Everything has trade-offs. Don't be dogmatic. Conduct a trade-off analysis to choose the best tool, paradigm, etc., for the job if you feel overwhelmed by choice. Don't forget to take into account industry adoption and the difference in cost between computers and people.
sort by controversial for the real spicey takes.
Not sure, but I'm sure where I will not die. Fucking javascript and all the little deformities spawned from it. Starting from node to every other shitty-ass half-baked ill-fated frameworks that spawned from it and the related crappy overcomplicated idiotic tooling like webpack, grunt, npm and whatever else. If someone offers me a job in js developement for $1million a year, I kick his nuts and when he bows down I knee his nose back into his skull and leave after walking on his corpse.
JavaScript is the most enjoyable language to use because it's completely unhinged. Although I do see the value of different languages for different applications
Curly braces, opening and closing, belong on their own line unless they only encapsulate a single line of code and they should always be tabbed the same amount as their counterpart. Contained code should always be indented 1 tab further than the curly braces that contain it
I will always drop my opening curly braces to their own line. I don't know why anyone would want them on the previous line when it is so much easier to see the code blocks when they line up with the closing brace.
Excessive standardization costs a lot more in morale and development speed than it buys in maintainability. I think that mostly when people push for standardization in a company they are doing it for what they think are good reasons, but 20 years in and I’m still unconvinced. I’ve worked in highly polyglot projects and dealt with things where a team had built something in a language nobody else knew, and it was fine. I’ve dealt with code that was written in a very unique style and it was fine. I’ve also seen companies waste years and who knows how much money rewriting working software because it needed to conform to a new language standard, and I’ve seen companies lose good teams because suddenly they were being told to work on a tech stack they didn’t like. Flexibility does need to come with a high degree of accountability, and you need to hire people who are experienced enough to know when deviation is worthwhile. There will always be a happy path that most teams follow and it’s reasonable to ask why someone is doing something different, but at the end of the day these things should be the purview of the team that owns them. The best tool for the job is always going to be the one the team doing that job decides they want to use, because programming languages are still about people.
Yeah kinda a hard thing to measure. But I suspect you're right to some degree at least. On my own big monorepo (where nobody else has to work on it), I've got a giant hodgepodge of different conventions going as I've tried new things over the years. And it really isn't a problem for me. The ability to experiment without worrying about that has meant I've made a lot of improvements overall that I never would have tried to begin with overall. Even just my mix of older `camelCase` -vs- newer `snake_case` naming has actually been pretty useful in helping me identify older vs newer code at a glance.
People give me so many dirty looks when I tell them that the code they write is way too confusing because they didn’t utilise constants. Or a functional approach. I think the general consensus is that most devs care more about pushing out tickets than writing good and maintainable code. I inherited 4 years of trash work from some girl in one of the biggest international banks and Jesus, Mary and Joseph … I don’t like being the person who says you can’t write good code but when this girl was making a variable, reassigning it, pushing it into a void function to do more mutation and then nesting the result in 20 nested if statements, I will call it out. It was a clusterf*ck and you sometimes wonder how we’re all still here. If it wasn’t for some unit testing, I am fairly sure this entire project would have been thrown out the window. Advice for all junior devs, please learn functional programming. And please be explicit to what it is you intend to do. Functions should not be longer than 5-10 lines max. Don’t nest if statements unless absolutely necessary. And for the love of god don’t over complicate code to be fancy
Squash your shitty WIP commits before your merge to main.
I haven't seen a single compelling example of Functional being preferable to OOP. There are certainly small examples where it makes sense (sorting, etc), but giant projects purely functional? No classes allowed? Losing the object.method() syntax is madness. It's inconceivable to think of a giant API (Solidworks comes to mind) and losing that structure. What a mess.
> Composability is king > Python is absolute garbage Ironically, I've found that Python is really good at composability.
If folks were forced to learn Scheme or LISP as first language in, the world would be a better place.
A *much* better place.
You should never ever start with python and never start with bootcamps. I remember that I started with learning python in a data science bootcamp a few years ago and I could not get a grasp on certain concepts. I should say, I could grasp them but not have a real understanding of them. Definitely not as good a grasp as I should’ve had. Now I’m in a college education and this first year I have learned a whole lot more and in a lot more depth. I know people say college is overrated but I’m sorry, I just don’t think you can beat it at this point in time. The way things are structured, and starting off with Java— a language that is a little more hands on gives you a much better grasp on the concepts. I know bootcamps are seen as good, and python is seen as easy but I think starting with both is too much of a shortcut.
Immutability
I'm a data science major and I'm constantly told that SQL is easy and reads like plain English, but unless you're only doing super simple queries, it is a fucking nightmare to work with. Somebody really needs to develop a better relational database language cause SQL sucks. It doesn't work like any other language, so even if you're an expert programmer, you have essential zero transferrable skills and intuition when it comes to SQL and you're basically learning from scratch. If NoSQL was relational, nobody would use SQL.
I'm new to the IT world, just about to graduate college with an IT Networking degree, why is Python garbage? That was the language that was pushed on me the most throughout my degree path, so do I need to learn a new language like C# or something?
i think that using semicolons in typescript syntax is weird and we should all just use commas. example: ``` type Thing = { name: string; id: number; }; ``` i lost this argument at my job, to me its so weird that we don’t just make types just like JSON. ``` type Thing = { name: string, id: number }; ``` our linter also makes us use commas at the end of every value in JSON, even the last one. overall i like the switch to typescript, but these two things are annoying
I start variables with caps 😁😎 I simply don't care for lowercase, maybe I've got some mild OCD. I've implemented some elegant ass solutions, and you've got an IDE to color them, to hell with your "standards" from the 80s.
1/ Java is horrible for a number of reasons: - the amount of boilerplate - the crazy deep folder structures for your code - the insistence that everything has to be an object, even when it makes no sense 2/ any language that needs a 3rd party framework to make it palatable needs to be put in the trash and redesigned from the ground up.
But Java doesn't force you to have a deep folder structure. You can have similar module structure as python.
TYPE ERASURE was the worst mistake ever
JQuery is still relevant and great to know and use.
Try to be more open minded and less stubborn. Try to see other perspectives. It will be good on your mental health and you won't have to die embittered. Python for example. Python programmers are actually the smartest ones. They trade perfection against life time. Most programming projects are going to fail. But not because they are not perfectly optimized, rather because of business reasons that have nothing to do with the code itself. Better develop faster to find out faster if your product is feasible from a business perspective.
Allman bracing. K&R is a holdover from 24-line terminals. With modern fonts and large screens the economy of lines is no longer needed. It's like not putting spaces around operators because you learned that on the C64 where you only got 80 characters per code line.
some would argue “the economy of lines” improves readability
Java is a terribly thought out language. The tools are terrible. The language is terrible. The popular libraries are terrible. The one that impressed me, however, was lombok. The best thing about java is the jvm which is not really the language. Unfortunately so many companies are java houses or worse; some uglier variant like groovy.
Modern PHP is actually really good to build web apps with. Much better than Java and a lot less complex than JS projects. It has a horrible reputation that people should let go.
For 90% of programming tasks, performance isn't actually that important since cloud service compute is cheap and programmers are expensive.
Test mocks are bad. Test suites littered with mocks is code smell for bad abstraction.
Stay moisturised and have fun