Neil Degrasse Tyson does Cosmos

metalman said:
Nature is feminine and science and technology are patriarchal, claiming to be "objective". "objective" is a patriarchal construct made by white cis-het men
Click to expand...
And Neil DeGrasse Tyson is... what? Trans-white?
 
metalman said:
Programmers the world over, all slapping their foreheads in shame.
"That's all we had to do!"


https://twitter.com/x/status/551378648578916353

Problem Solved!!

its not the programmer that causes the problems, its the "users" ;)

if you want an infallible computer system, you must limit users to "The Pope"
Click to expand...
I know from experience in general software is of EXTREMELY poor quality. Even popular programming languages themselves are extremely poor, with PHP and ASP at the very bottom of the dungpile.
I've seen code that didn't use any paradigm, didn't use functions/procedures whatsoever. It was one big heap of if-then-else statements - and this was made by ICT graduates.
I've seen a Magento system being hacked because it had a 'feature' so site admins could submit code via the site to be run on the server(!!!!!!)
There's such a thing as sql injection.
Buffer overloads here and stack overflows there because we can't be bothered to deal with the fact that a computer has limitations.
And if for instance you use Linux, and if you want to remove files because a directory is becoming a bit full, you can expect an undocumented error "Argument list too long". Yes, when is this list too long? The man pages don't state it. If you google it, some wiseguys will friendly point out you can use the command "find . -name '*' -delete", aaaand on we go, happily ignoring the error so others will fall victim to this at most inconvenient times. Not to mention all these sed and awk trash that actually prevents people to make decent program communication through data standards like JSON, ProtocolBuffers or AVRO. I've totally had it with this trash. Time to ditch it and make it properly.

So yea, I'm with mister Tyson on this one. Shame on many many programmers.
 
Speelgoedmannetje said:
I know from experience in general software is of EXTREMELY poor quality. Even popular programming languages themselves are extremely poor, with PHP and ASP at the very bottom of the dungpile.
[...] I've totally had it with this trash. Time to ditch it and make it properly.
Click to expand...

it's worse than that and will never get better - because everyone is trying to make it better - on their own.

Everyone re-invents the wheel because that is faster than understanding the wheel. There are fifty-billion wheels and it will take you weeks to just survey the existing wheels or the favourite wheels or the wheels that most people are using. Then you realise that some wheels are no longer maintained - which could mean that there is nothing left to fix actually, but nobody wants to take the chance that it means it is somehow totally broken and you will never get anyone to fix it. Some wheels have been maintained for so long that the feature list is full of esoteric and incompatible options and they are too bloated or too complex to use in your application. Besides, the only part of the wheel you really need right now is the hub and the rim - the rest you can worry about later - so you decide to make your own mini wheel. You never get around to evaluating the other wheels because you have a wheel that is fine, except when it needs a new feature, which you add. Soon the wheel becomes a library or a package or a framework and it becomes another wheel in the world of wheels that some people will use (and many will ignore) and the more it is used the more features will be requested until it's just another incompatible bloated wheel like all the rest and everybody starting a new project knows that all the wheels are bad and they can do better and besides, they just need a hub and a rim and that will be quicker than evaluating the other wheels ... and round, and round, and round.

From time to time we create a new language so we can try to create better described new wheels this time but we always run into the same problems that made the old wheels bad when we get to the edge cases. And what goes for wheels, goes for languages.

You end up with dungpiles made of dungpiles on top of other dungpiles - and if you change one of the dungpiles all the other dung will fall all over the place.
 
FluffyMcDeath said:
it's worse than that and will never get better - because everyone is trying to make it better - on their own.

Everyone re-invents the wheel because that is faster than understanding the wheel. There are fifty-billion wheels and it will take you weeks to just survey the existing wheels or the favourite wheels or the wheels that most people are using. Then you realise that some wheels are no longer maintained - which could mean that there is nothing left to fix actually, but nobody wants to take the chance that it means it is somehow totally broken and you will never get anyone to fix it. Some wheels have been maintained for so long that the feature list is full of esoteric and incompatible options and they are too bloated or too complex to use in your application. Besides, the only part of the wheel you really need right now is the hub and the rim - the rest you can worry about later - so you decide to make your own mini wheel. You never get around to evaluating the other wheels because you have a wheel that is fine, except when it needs a new feature, which you add. Soon the wheel becomes a library or a package or a framework and it becomes another wheel in the world of wheels that some people will use (and many will ignore) and the more it is used the more features will be requested until it's just another incompatible bloated wheel like all the rest and everybody starting a new project knows that all the wheels are bad and they can do better and besides, they just need a hub and a rim and that will be quicker than evaluating the other wheels ... and round, and round, and round.

From time to time we create a new language so we can try to create better described new wheels this time but we always run into the same problems that made the old wheels bad when we get to the edge cases. And what goes for wheels, goes for languages.

You end up with dungpiles made of dungpiles on top of other dungpiles - and if you change one of the dungpiles all the other dung will fall all over the place.
Click to expand...
Fantastic post.
You've articulated far better than I could something I moan about almost every day yet am regularly guilty of myself. :lol:
 
FluffyMcDeath said:
it's worse than that and will never get better - because everyone is trying to make it better - on their own.

Everyone re-invents the wheel because that is faster than understanding the wheel. There are fifty-billion wheels and it will take you weeks to just survey the existing wheels or the favourite wheels or the wheels that most people are using. Then you realise that some wheels are no longer maintained - which could mean that there is nothing left to fix actually, but nobody wants to take the chance that it means it is somehow totally broken and you will never get anyone to fix it. Some wheels have been maintained for so long that the feature list is full of esoteric and incompatible options and they are too bloated or too complex to use in your application. Besides, the only part of the wheel you really need right now is the hub and the rim - the rest you can worry about later - so you decide to make your own mini wheel. You never get around to evaluating the other wheels because you have a wheel that is fine, except when it needs a new feature, which you add. Soon the wheel becomes a library or a package or a framework and it becomes another wheel in the world of wheels that some people will use (and many will ignore) and the more it is used the more features will be requested until it's just another incompatible bloated wheel like all the rest and everybody starting a new project knows that all the wheels are bad and they can do better and besides, they just need a hub and a rim and that will be quicker than evaluating the other wheels ... and round, and round, and round.

From time to time we create a new language so we can try to create better described new wheels this time but we always run into the same problems that made the old wheels bad when we get to the edge cases. And what goes for wheels, goes for languages.

You end up with dungpiles made of dungpiles on top of other dungpiles - and if you change one of the dungpiles all the other dung will fall all over the place.
Click to expand...
Not everything is dungpiles though.
With languages like Clojure, Scala and F# we slowly move towards a more declarative form of coding, which will tremendously increase software quality. Or at least give good coders the appropriate tools to do so. Not everything is a dungpile, there is good code, that handle extremely difficult principles very concise and straightforward.
Some herald the functional paradigm as the be-all-end-all paradigm, the Lisp coders boast about every idea could be realized in Lisp even before the stars were born, and scorn the OO approaches.
I'm thinking further, I think there's a great declarative part in OO that I've extensively used over the years. It greatly (but not fully) supported my semantical approaches to software development. Your own language is the key too to good software development, and choosing the proper words that atomically pinpoint aspects of the requirements will enable you to do more with your code than you ever thought possible. Or even turn around your perspective on the requirements altogether. Considering that, a good programming language is a programming language that lets you define your paradigm approaches (or: OO, AO or Functional problem approaches) with minimal fundemental alterations.
 
Last edited:
That being said, I've spent more than a month writing a (retrofitting) system that works with Kafka in a declarative manner in Java. I never tested anything during that time as it could only be tested when it was complete. And it worked because it worked per definition. Normally I do a lot of test driven design as the tests are my definitions, but this code was almost 100% definition, except for the request/response calls.
 
Last edited:
Speelgoedmannetje said:
That being said, I've spent more than a month writing a (retrofitting) system that works with Kafka in a declarative manner in Java. I never tested anything during that time as it could only be tested when it was complete. And it worked because it worked per definition. Normally I do a lot of test driven design as the tests are my definitions, but this code was almost 100% definition, except for the request/response calls.
Click to expand...

I've seen some nice code, but there s a powerful and corrosive force that works on a code base over time. There's always a hot patch that needs to work yesterday (and it'll be ugly but we'll fix it when we get some time - which never comes, at least not before someone depends on the hack). There's always an unanticipated feature or worse, two contradictory features, both absolutely essential to different big customers you can't afford to lose. etc. etc. And there is the relentless market pressure - yes, it's good to be the est, but if you are the FIRST then you are de facto the best - for now and if you grab share you can fix stuff later.
 
You must log in or register to reply here.
Back
Top