Mark Rendle's talk was not recorded, as it took place at a different venue. However, you can download the slides here: gotocph.com/2021/sessions/1999/the-worst-programming-language-ever
Spoilers: it's literally a combination of the worst features from different languages to create a fictional PHP-like language (already a bad language, but why not make it MUCH worse) called BS
Agree with Eric, being able to code in same language and ecosystem for both frontend and backend is a big deal. Performance is not a big deal for most applications, you just have to not be very bad.
This whole divide between frontend and backend is itself an artificial construct that someone once thought was a great idea. The fact that we took that great idea to extremes, and created 2 sets of teams that speak in different languages and can barely communicate with each other is interesting as well. Not so sure about saying performance is not a big deal. Even small and seemingly trivial things can get repeatedly run thousands of times in their lifespan, and/or on millions of devices. Performance and efficient resource usage should be one of our primary goals at all times. It's always worth losing a bit of sleep over. Never knock off, or go to bed if you know a slightly better way to do what you are doing.
Type checks should be defined in the class imho, not the language. If types are important enforce them manually, if not then allow any type where no check is required. Way less overhead than making a strict type system flexible as opposed to making a loose type system strict only when necessary.
Bjarne Stroustrup in every talk has highlighted the importance of having a strong type system and static typing ! It's funny to see folks re-hash and re-package the same ideas ALL the time 😀 Folks who say you don't a type system haven't written significant code enough to appreciate the importance !
the history of OO is the history at failing to manage or handle any kind of state in any kind of applications, even in state light apps and even worse in state heavy apps.
While Erik was talking about how the transpilation approach (to JavaScript) didn't really work out, I can imagine that Richard was thinking: Is Elm a joke to you?
the reason people are conflicted about types is that people haven't thought really what types give you and how to use them as a design tool, you only are thinking on them as locks to set rigid your code so then you don't have problems. But even in small codebases for a single user AKA programming in the small, types help you document your code, and establish your goals for your script/configuration and avoid wasting time iterating on finding type errors and focus that time to find logic errors.
the talk about "gc pauses" and "faster", etc are missing the point. it's about whether you can MISS DEADLINES. Even if you have a GC, you need some threads that absolutely cannot miss deadlines. This is because if the code is driving a vehicle; the vehicle is DESTROYED IN A CRASH when it misses deadlines. RT Linux effectively runs two kernels, so that one kernel never misses deadlines, and the other one is best-effort timing.
They seem focused on compiler tech... No mention of the psycholinguistics of programming. I'd like to hear more discussion about BCI-first language design
@3:38 "..design the language for everything, and that is the first mistake...". Well, I disagree. We're using languages for purposes for which they are totally unsuitable. For tasks they were never designed for. Python is used for large-scale, scientific and server software, C for safety-critical systems, etc. It goes to show we have quite a huge margin. Shoot in the middle and you'll hit everything.
seriously, when is people going to understand that OO was some serious fuck up? that tells me those programmers that think "I want both" are just not good developers, because they don't think, they don't analyze. There is not a single feature of OO that is top notch. Only developer who don't analyze the world, who don't question who don't have an inquisitive mind thought that OO had won. Every OO feature has either proven to be counter-productive, to cause more problems than it promised to solved, and even for those problems that it promised to solve, there are better alternatives. Classic and fundamental feature of OO is inheritance, and now everyone knows that composition or delegation are better than inheritance, there is not a single case in which inheritance is a better option. Encapsulation as interpreted by Java/C++ was always a meme and it collapsed with multicore, in Java you have public/protected/private levels of access in classes and then what do we do, declare private/protected properties and then break that with getters/setters, lol. And we can keep going on with any feature of OO. they all suck and they all have superior alternatives. OO is a failure. also gradual typing is like masturbation. untyped languages are really languages that have types but avoid to take advantage of the types.
I don't think it's helpful to think that since a class wasn't replaced within 2 years that it wasn't worth the extra thought and effort to make code maleable for the future. The point is to not have to spend a full redevelopment cost on long term codebase, but web dev code doesn't need to last more than 5 years. It SHOULD be rewritten anyway since web technologies and frameworks evolve so quickly. Java codebase though, should be written with long term in mind. 2 years without rewriting an established class doesn't say anything at all imho
I agree. Because if a class or assembly has to be rewritten, you aren't going to retain as much knowlege 5 years in the futire... making it more maintainable for future devs is what the point is of having those "seams" in the code.
yes, we like to categorize and we can do that better with a sound type system than with classes, because we implement simple labels as types and then add typeclasses/traits as a way to say "this type can do this things" we have a free way to categorize and then associate behavior freely and with a sound type system when we associate the behavior to a type the behavior is implemented automatically like in Haskell. When it comes to developer preference of programming paradigms, exposure and order of exposure is a significant factor, for some reason our brain gets primed to define what programming is based on our first experience of programming. I have met a lot of programmers who learned OO first or procedural first and then they decided to shift to other paradigms, some returned other stayed in the new paradigm, however I have never met a person who learned FP first and then tasted OO and wanted to stay in OO. So to me the guys who preferred Kotlin over Clojure is guys who are just primed by OO and have their brains hardcoded for OO and the effort required to change the paradigm is just not there, because objectively in code, FP is superior to OO. And I have an additional argument to make is not just about being primed to do OO, is to do a special flavor of OO, because Clojure is even more object oriented than Kotlin, because it has multimethods and protocols, which are a superior form of dynamic dispatch to anything that Java or Kotlin can provide.
Good Video thanks! As a side question, the host of the presentation mentioned his association with Erlang. I like the concept of Erlang in principle. How does Erlang handle containers, In particular, can Erlang be used in the Kubernetes environment to monitor containers and services?
So one thing that's worth mentioning is that Erlang's Beam VM and OTP library already tried to solve a lot of the same problems that Kubernetes attempts to solve. They handle instance failure & recovery, hot reloading, rolling deploys, minimum # of instances, and even things like leader failure. The major difference is that Kubernetes is more generally applicable since you aren't tied to something that has to output Beam bytecode, so you can port your existing apps over to it more easily. Given all that, you do need to assess the question of whether it's worth using both in conjunction. I'm not going to say anything one way or the other since it depends too much on specifics. That said, I have seen documentation on using the two in conjunction. I can't seem to find any now, and I never really dug into it, but it's definitely something people have looked into.
I agree, Kotlin Is the best compromise to any language today: good type system, good functional programming, garbage collected, super tooling, good testing libraries, autocompletion and super easy large scale refactoring with intellij.
In companies and medium- to large-scale projects Typescript is almost always the preference over JS. What hidden power can you use with JS that you cannot with TS?
I hear that a lot... but what exactly is lost? I hear "flexibillity", but in practice flexibillity means typos and undefined is not a function. I realy can't see anything lost when going to TS, since with duck typing/structural typing, you still can do everything you want, but without typos
Functional programming is like one hand clapping. At it’s most basic level, programming is about data and code not just code. Pure functions can be written in every language I have ever used so FP didn’t invent pure functions. FP just says that’s all you should use! OOP doesn’t require inheritance which has more problems than positive uses but encapsulation is the key to finding bugs and producing good code.
@@MrHamsterbacke756 Exactly. It’s about playing hot potato with data as some kind of defect that needs to be sequestered or eliminated. So FP systems just put all their data in the database so they can pretend to be pure. It is just ridiculous! Programming is about data and code, not just code. The analogy of “the Emperor with no cloths” comes to mind when dealing with the absurdities of FP. If FP proponents say that mutating data is the route of all evil, then prove it. If Math notations are so great for code, prove it. Is COW the answer? What about all the extra writing, garbage collecting and complexity? I could go on but I suspect that people will just continue with the FP nonsense regardless.
@@MrHamsterbacke756 I have just recently watched a Russian on TH-cam create a “concatenative” language made of “words” that also reads like a language and composes many functions. Lisp was invented in the late 1950’s and it also did both those things, so what?
Do you guys know that Nodejs is much much faster on the backend than Java and Kotlin? Mostly because of their crappy frameworks and threading model? No you don't, and that's a shame.
I can see that Rust, and the surge of wishful thinking driving it's mass adoption, has all the makings of a train crash of epic proportions. Check back in few years from now, and you will see what I mean. The problem isn't the tools.
What were the Worse languages?
Mark Rendle's talk was not recorded, as it took place at a different venue. However, you can download the slides here:
gotocph.com/2021/sessions/1999/the-worst-programming-language-ever
@@GOTO- I'll wait for the upload 😁 that sounds like a fun watch lol
@@GOTO- th-cam.com/video/hCvHTrUh4os/w-d-xo.html
BS
Spoilers: it's literally a combination of the worst features from different languages to create a fictional PHP-like language (already a bad language, but why not make it MUCH worse) called BS
Richard is on a different level. Respect.
Agree with Eric, being able to code in same language and ecosystem for both frontend and backend is a big deal. Performance is not a big deal for most applications, you just have to not be very bad.
This whole divide between frontend and backend is itself an artificial construct that someone once thought was a great idea.
The fact that we took that great idea to extremes, and created 2 sets of teams that speak in different languages and can barely communicate with each other is interesting as well.
Not so sure about saying performance is not a big deal. Even small and seemingly trivial things can get repeatedly run thousands of times in their lifespan, and/or on millions of devices.
Performance and efficient resource usage should be one of our primary goals at all times. It's always worth losing a bit of sleep over.
Never knock off, or go to bed if you know a slightly better way to do what you are doing.
4:30 - Totally agree with that. Having a good type system really helps navigate and understand the code.
Type checks should be defined in the class imho, not the language. If types are important enforce them manually, if not then allow any type where no check is required. Way less overhead than making a strict type system flexible as opposed to making a loose type system strict only when necessary.
I don't. If you have to know the types to understand the code, it is poorly written.
Bjarne Stroustrup in every talk has highlighted the importance of having a strong type system and static typing !
It's funny to see folks re-hash and re-package the same ideas ALL the time 😀
Folks who say you don't a type system haven't written significant code enough to appreciate the importance !
Have tried several languages, imo F# is the best 😁
the history of OO is the history at failing to manage or handle any kind of state in any kind of applications, even in state light apps and even worse in state heavy apps.
While Erik was talking about how the transpilation approach (to JavaScript) didn't really work out, I can imagine that Richard was thinking: Is Elm a joke to you?
the reason people are conflicted about types is that people haven't thought really what types give you and how to use them as a design tool, you only are thinking on them as locks to set rigid your code so then you don't have problems. But even in small codebases for a single user AKA programming in the small, types help you document your code, and establish your goals for your script/configuration and avoid wasting time iterating on finding type errors and focus that time to find logic errors.
This talk is really eye-opening...
The answer hasn't changed since 1968. It is either Algol or Lisp.
the talk about "gc pauses" and "faster", etc are missing the point. it's about whether you can MISS DEADLINES. Even if you have a GC, you need some threads that absolutely cannot miss deadlines. This is because if the code is driving a vehicle; the vehicle is DESTROYED IN A CRASH when it misses deadlines. RT Linux effectively runs two kernels, so that one kernel never misses deadlines, and the other one is best-effort timing.
They seem focused on compiler tech... No mention of the psycholinguistics of programming. I'd like to hear more discussion about BCI-first language design
Zig is very interesting, I've been keeping it in the corner of my eye for a while now.
Is it possible in future, to write web backend development in zig?? Or is it specifically to replace c as system language ??
there’s a zig web framework called zap. it’s pretty minimal tho.
😉 by now you would have got a 'stye' in your eye 🤣
Richard looks like he is a brother of Hannah Fry.
@3:38 "..design the language for everything, and that is the first mistake...". Well, I disagree. We're using languages for purposes for which they are totally unsuitable. For tasks they were never designed for. Python is used for large-scale, scientific and server software, C for safety-critical systems, etc. It goes to show we have quite a huge margin. Shoot in the middle and you'll hit everything.
> C
> safe
bruh
So, am I the only "language nerd" on Earth who loves JavaScript?
seriously, when is people going to understand that OO was some serious fuck up? that tells me those programmers that think "I want both" are just not good developers, because they don't think, they don't analyze. There is not a single feature of OO that is top notch. Only developer who don't analyze the world, who don't question who don't have an inquisitive mind thought that OO had won.
Every OO feature has either proven to be counter-productive, to cause more problems than it promised to solved, and even for those problems that it promised to solve, there are better alternatives. Classic and fundamental feature of OO is inheritance, and now everyone knows that composition or delegation are better than inheritance, there is not a single case in which inheritance is a better option. Encapsulation as interpreted by Java/C++ was always a meme and it collapsed with multicore, in Java you have public/protected/private levels of access in classes and then what do we do, declare private/protected properties and then break that with getters/setters, lol.
And we can keep going on with any feature of OO. they all suck and they all have superior alternatives. OO is a failure.
also gradual typing is like masturbation.
untyped languages are really languages that have types but avoid to take advantage of the types.
Thank you. OOP sucks but mist people can't see why. You explained it very well.
I don't think it's helpful to think that since a class wasn't replaced within 2 years that it wasn't worth the extra thought and effort to make code maleable for the future. The point is to not have to spend a full redevelopment cost on long term codebase, but web dev code doesn't need to last more than 5 years. It SHOULD be rewritten anyway since web technologies and frameworks evolve so quickly. Java codebase though, should be written with long term in mind. 2 years without rewriting an established class doesn't say anything at all imho
I agree. Because if a class or assembly has to be rewritten, you aren't going to retain as much knowlege 5 years in the futire... making it more maintainable for future devs is what the point is of having those "seams" in the code.
yes, we like to categorize and we can do that better with a sound type system than with classes, because we implement simple labels as types and then add typeclasses/traits as a way to say "this type can do this things" we have a free way to categorize and then associate behavior freely and with a sound type system when we associate the behavior to a type the behavior is implemented automatically like in Haskell.
When it comes to developer preference of programming paradigms, exposure and order of exposure is a significant factor, for some reason our brain gets primed to define what programming is based on our first experience of programming. I have met a lot of programmers who learned OO first or procedural first and then they decided to shift to other paradigms, some returned other stayed in the new paradigm, however I have never met a person who learned FP first and then tasted OO and wanted to stay in OO. So to me the guys who preferred Kotlin over Clojure is guys who are just primed by OO and have their brains hardcoded for OO and the effort required to change the paradigm is just not there, because objectively in code, FP is superior to OO. And I have an additional argument to make is not just about being primed to do OO, is to do a special flavor of OO, because Clojure is even more object oriented than Kotlin, because it has multimethods and protocols, which are a superior form of dynamic dispatch to anything that Java or Kotlin can provide.
Good Video thanks! As a side question, the host of the presentation mentioned his association with Erlang. I like the concept of Erlang in principle. How does Erlang handle containers, In particular, can Erlang be used in the Kubernetes environment to monitor containers and services?
Containers are not related to programming languages. A container can be built with anything inside of it.
So one thing that's worth mentioning is that Erlang's Beam VM and OTP library already tried to solve a lot of the same problems that Kubernetes attempts to solve. They handle instance failure & recovery, hot reloading, rolling deploys, minimum # of instances, and even things like leader failure. The major difference is that Kubernetes is more generally applicable since you aren't tied to something that has to output Beam bytecode, so you can port your existing apps over to it more easily.
Given all that, you do need to assess the question of whether it's worth using both in conjunction. I'm not going to say anything one way or the other since it depends too much on specifics. That said, I have seen documentation on using the two in conjunction. I can't seem to find any now, and I never really dug into it, but it's definitely something people have looked into.
What about @ballerinalang for typical data-intensive, service-oriented enterprise applications?
I agree, Kotlin Is the best compromise to any language today: good type system, good functional programming, garbage collected, super tooling, good testing libraries, autocompletion and super easy large scale refactoring with intellij.
Ehhh so is C#
@@metaltyphoon i don't want do a language war. But i found c# a bit more verbose. It Is only my personal useless opinion of style. 😆
Maybe have a look at F# then ^^
You spelled Godot wrong.
TypeScript is a winner? It hides everything that is the power of Javascript.
In companies and medium- to large-scale projects Typescript is almost always the preference over JS.
What hidden power can you use with JS that you cannot with TS?
I hear that a lot... but what exactly is lost? I hear "flexibillity", but in practice flexibillity means typos and undefined is not a function. I realy can't see anything lost when going to TS, since with duck typing/structural typing, you still can do everything you want, but without typos
if by "power" you mean acting like a monkey with a razor blade
Kabilang mundo
Functional programming is like one hand clapping. At it’s most basic level, programming is about data and code not just code. Pure functions can be written in every language I have ever used so FP didn’t invent pure functions. FP just says that’s all you should use! OOP doesn’t require inheritance which has more problems than positive uses but encapsulation is the key to finding bugs and producing good code.
FP is not about pure functons, it's about a different way of thinkg about functions, data and actions.
@@MrHamsterbacke756 Exactly. It’s about playing hot potato with data as some kind of defect that needs to be sequestered or eliminated. So FP systems just put all their data in the database so they can pretend to be pure. It is just ridiculous! Programming is about data and code, not just code. The analogy of “the Emperor with no cloths” comes to mind when dealing with the absurdities of FP. If FP proponents say that mutating data is the route of all evil, then prove it. If Math notations are so great for code, prove it. Is COW the answer? What about all the extra writing, garbage collecting and complexity? I could go on but I suspect that people will just continue with the FP nonsense regardless.
True FP adoption would show itself in the code, functions being composed and eventually reads like a prose.
@@MrHamsterbacke756 I have just recently watched a Russian on TH-cam create a “concatenative” language made of “words” that also reads like a language and composes many functions. Lisp was invented in the late 1950’s and it also did both those things, so what?
One hand clapping, data and code not just code.
In future please do not describe things like this.
kotlin, dart, rust
these guys are stuck in 2003
Do you guys know that Nodejs is much much faster on the backend than Java and Kotlin? Mostly because of their crappy frameworks and threading model? No you don't, and that's a shame.
Any supporting links that show that?
Performance is often not that important but ecosystem and node has a long way to go for that.
@@NathanHedglin are you kidding?
"waiting for proper replacement for js" hshshhahahahaha haa ahh ah, language geeks and wishful thinking
I can see that Rust, and the surge of wishful thinking driving it's mass adoption, has all the makings of a train crash of epic proportions.
Check back in few years from now, and you will see what I mean.
The problem isn't the tools.
A year has passed and I don‘t see what you mean.
You sound very vague and condescending, please explain.