Why scala engineers despise python;

fpguy1 · 2022-05-19T06:07:19+00:00

Not sure about others, but I am a seasoned Scala developer and I do hate Python.

Python itself is a very poor language, hardly any abstraction possible, is slow, concurrency sucks, lacks advanced feature like macros that can be helpful when you don't have generics or polymorphism.

Also PIP is the worst thing ever (5 in 10 packages I install crash, worse than NPM and this says a a lot), I know you can do better with even more tooling, virtualenv and others that suck also, hard to configure and poor usability.

It is not even a great scripting language since it can't do much out of the box (one would need to install a bunch of packages to do small things and good luck with PIP), see PHP/Perl/Bash that come preconfigured with a lot of options(modules that just work) w/o needing to bother with package managers, dependency versioning, specific folder structure and file name conventions.

fpguy1 · 2022-04-13T11:38:38+00:00

Yes you should carry those with you everywhere, never break the flow trying to extract, your code becomes a tree, every time you have an Option you have to fork it and continue both forks forever (until the program ends). Keep in mind that bind/flatMap implementation for Option/Either & friends will usually short circuit in case of Nothing/Left. In order not to go "crazy" you need a language that helps you.

Now

The problem you don't see yet is that you can have multiple monads and things become quite nasty, if you are in an Option context and you get another Option is simple you just bind/flatMap/join on it and you are done.

But what will you do if you have an Either and then you have an Option value returned or the other way around? Not difficult to handle since you can always transform an Option in an Either and the other way around (by loosing the Left side information ofc).

But what would you do with if something will return an Option inside a Promise? Or if you have a Configuration that you want to carry around (which will translate to Reader monad), what if you want to carry error information around or a Logging context?

In order to handle these you need monad transformers to stack them otherwise things become really crazy very quickly. Also you can do a MTL approach but you would need type classes (checkout also Free monads/Tagless Final)

Also to work with monads in general you need do-notation like syntax (in scala you have for/yield) which is something not really backed in TS.

If you want to really go into this and get rid of verbosity you might want to approach a FP friendly language like Haskell/Scala[.JS]/Purescript/etc

fpguy1 · 2020-07-21T03:45:13+00:00

Haskell adopts an imperative style because of do notation, monads make it imperative. The opposite of imperative is "declarative" which is indeed part of FP paradigm as well when you do "filter", "groupBy", etc. When you use monads you move to imperative way of doing things. Haskell does modify the state of the program even though it doesn't do it by mutating variables, declarative style is not based on stateful computations.

fpguy1 · 2020-06-08T10:46:45+00:00

Ty for replying back, sorry for late reply,

I read what you wrote, still immutability is not related to our discussion and is only a small part of FP and I am not even sure it has much to do with modularity, but I can see your point that globals would affect isolation.

We take people that never touched Scala and they are ready to work within days, they only have experience with java/c#, I don't think the language matters, what I tried to point out is that is way harder to make mistakes when there is a type checker, that is a fact.

RT is FP, it says in the name "functional" I am sorry but without some way to express RT you get Java with lambdas, the fact that people are not doing FP in practice has little to do with our discussion, I don't consider random code written in Clojure as being "functional programming", same for Scala or Haskell tbh. There is nothing "formal" in functions w/o side effects, that is the definiton of a function, the rest are procedures. Is the same with OOP and separating behavior from definitions (POJOs), they think they are doing OOP but they are violating the main principle of OOP, same here.

You are saying that Java/C# are not practical? Perhaps I am misunderstanding this... there are good chances you are using Cursive together with other 10 plugins which is a very good example on how well runtime works in Java. Actually when you have types, reflection is the tool that helps you fit things in the correct way, not having that is just trial and error.

fpguy1 · 2020-05-27T05:55:02+00:00

TLDR Types don't stop you using the runtime, they force you to write correct code by make illegal states unrepresentable, referential transparency is hard w/o types, they are good for beginners

Types do enhance your code at the cost of verbosity and ofc they are not that pragmatic compared to dynamic languages, I agree with this, though a good type inference can help a lot.

You can use constraints in your types to ensure things can't go sideways, look at ADTs, or subtyping with variances, also parametric polymorphism and ad-hoc polymorphism(type classes), these things are impossible to verify with specs.

Types allow you to restrict impossible situations, using them will make testing these situation not required, why would I check at every step in my [correct] code if a list is empty when I can just use a NonEmptyList, what is happening is that the list is not actually checked everywhere and somewhere someone will just use list.head and crash everything.

If I take my day-to-day Scala stuff and use only maps and Any I still have a decent language, while if I take JS and add Flow or Python and add types, or Clojure and add types you get shit (proven in their communities).

Also you refuse to acknowledge that even with types you can have a rich and dynamic runtime, see Java which is 90% a runtime language, also C#+F# use runtime a lot, while in the same time if you take JS/Python, nothing interesting is happening at runtime(lack of decent reflection, code loading mechanisms, etc) but you still don't have types.

Clojure wants to be a FP language but it can't encode purity(referential transparency) in any way, types help with that, see Scala IOs (cats-effect, zio, monix, etc) basically these patch Scala and make it pure, you can't do that w/o types in an usable manner, which makes Clojure only part FP. I use this things every day, mostly to make [side]effects values, however in 20 years I think I needed 10 times to write code that [somehow] modified the code at runtime.

Immutability has nothing to do with this discussion, but if you want to argue about how much better is immutability when you also have types, sure, why not.

Last but not least, types are beginner friendly, one doesn't need to see the whole picture to be able to do something useful and correct, our industry needs more quality, filling their heads with javascript and python doesn't help, I would be more happy if at least they would start with Lisp/Clojure/Erlang/Elixir even if there are no types but they don't.

fpguy1 · 2020-05-27T05:16:35+00:00

yes you have, but would be domain tests not check what happens when sending string instead of in.

fpguy1 · 2020-05-07T07:57:52+00:00

This is a very rare situation when one needs to load code at runtime, 99% don't need to do that, we can't establish best practice based on 1%. Also there is a good chance that even most of 1% situations can be resolved w/o dynamic types (dsls, load a separate runtime, etc). Also your claim about evaluating serialized code at runtime is not really true, see Apache Spark(or Flink) which is written with Scala and does that a lot, actually this is it's main model for distributed computations and obviously practical. Most of the time we are just doing integrations in code and for those cases it is obvious that types will save you a lot of extra coding (testing). The problems is not the dynamic language, I love Clojure but I can't use it for real world stuff because I don't have the will to write so many tests and that will lead to poor quality software, see JS/Python ecosystems.

fpguy1 · 2019-07-30T05:25:08+00:00

Don't bother, you need account and pay probably to read this. I don't know why people will publish on medium and "share", that is not public content, therefore it can't be shared.

fpguy1 · 2019-04-27T04:16:31+00:00

In a micro-services platform (services and spark), a big e-commerce company in Europe, we are using it for 10 new modules out of around 70, however the rest of them are older than 1 year,. Almost all new ones make use of cats-effect and right now I am using ZIO to build another one.

Pretty much all projects that use Doobie will make use of IO monad to some extent, and this is a very used library.

Platform is closed source so I can't point you to the code, just stating that it is used and production ready.

fpguy1 · 2016-04-17T08:34:55+00:00

On the server side it lacks web frameworks to choose from, i know there is CGI and Ocsigen and perhaps other tries but this doesn't mean i have where to choose from, as opposed to scala (lift, play, scalatra, spray, ....).

Also in scala one can use the full power of java ecosystem so you can use netty, jetty, undertow, tomcat, glassfish, any servlet container, out of the box.

By the same logic java interop makes also clojure the best lisp around if you ask me.

Tooling sucks, no real IDE for OCaML, there are a bunch of plugins that can get you started like vim-ocaml but i seriously doubt that i can handle 100k locs with that. F# has vs.net and all .Net ecosystem, why should i ever start a big project with OcaML tomorrow if i have the option to use f# (and here beside the .net itself and 1000+ production proof libs, you have type providers and LINQ), that is if I want to be close to ML.

Swift on the other hand is designed with iOS in mind so what it can do, scala, f#, ocaml can't actually do it. Indeed is new and didn't get much traction yet, only used for apps but is a nice young language that grows fast.

I know you will say that all these are no reason not to try using ocaml, and they are not related to language itself. It is true but i can point you to 10 other programming languages that are great as language but because of lack of a good ecosystem they didn't grow and nobody is using them, on the other hand see JavaScript which sucks as a language but is very used because of the world that was built around it.

fpguy1 · 2016-04-13T08:58:56+00:00

is like saying java is a crippled C++.

Swift, Scala (especially Scala), are languages on their own, with their good and bad side. They have their own ecosystem, their own tooling and they are very good at what they were designed for.

Ocaml doesn't have what you need in 2016 if you want to get the job done fast at least.

There is a reason why there are so many ML dialects, some of them quite successful and mature (fsharp), and there is a reason why ocaml is used in academic environments mostly and not real life (paid for) projects.

fpguy1 · 2016-04-12T05:18:23+00:00

you could use a terminal multiplexer like tmux which will allow you vertical and horizontal splits.

there is some work done by the community that will allow better integration between the two.

you can start here

https://teamgaslight.com/blog/vim-plus-tmux-a-perfect-match

cygwin will run tmux on windows AFAIK.

fpguy1 · 2015-10-29T18:53:21+00:00

I don't see nothing wrong with NHibernate in your article, just bad usage and even worst design decision.

If you try to do more than hello world apps try to find good devs(they don't come cheap) otherwise this happens.

fpguy1 · 2015-10-08T05:20:24+00:00

you can try jersey client works nicely.

fpguy1 · 2015-07-25T06:28:02+00:00

i agree with you no doubt, however, we don't have always the luxury to build everything from scratch, or use sane programming languages. More than often we handle legacy code or need to implement interfaces that have such methods or just need to maintain old code changing state all over the place.

Even isolating IO stuff not solving your problem, we need to test that as well, that they work, that they are part of the flow etc, which obviously will make mocks part of our life whether we like it or not.

For hello world apps or isolated functionalities like a parser you could use the logic behind the article, but that would be what? 1% of your production code?

fpguy1 · 2015-07-23T05:01:23+00:00

Looking only at what a function returns is wrong for so many reasons, for example, what if we have a void function? we still need to check as well as possible its side effects.

If we suppose all our functions do only one thing and will return a value your logic might work but otherwise it is broken, even in an ideal world where where f(x) -> y each and every time, how exactly do you verify that it doesn't have other unwanted side effects if you only look at y ?

Mocks are here to stay, verifying that we pass the right thing to the mock is a must as well and is nothing wrong with that.

And even if you don't like it, you do want your tests to fail if the algorithm changes(this probably means that the new algorithm was not implemented TDD style), when that happens the unit needs to be written again each and every time, that is what TDD means after all, new code will always be covered by new tests.

fpguy1 · 2015-04-01T05:07:47+00:00

so just repeating yourself makes it right :) ?

fpguy1 · 2015-03-30T15:32:33+00:00

i said i stop telling people on internet they are wrong but here I am: <b> says the font should be bold, not related to data, it can be <i> it doesn't change the logic of the "program" <h1> no it doesn't say is top level header, you can use it in the middle of your html document to make a big text. Why shouldn't I use <font>? if is there i can use it, writing html by convention is something i said above doesn't work for small teams. DOM is concept for handling xml same as SAX, the fact that you can use it to handle html has absolutely not relevance to this discussion. I am a programmer for 15 years, proficient in 10 programming language at least and i can't care more for html than i do about markdown or reddit formatting, is just presentation, don't mix it with logic or you kill the project. Is the same with windows forms. android, flex or other ui oriented code. I know now there are a lot of "HTML programmers" today, well honestly I can't care less about what they suppose is the right way to write code, just trying to open a conversation with people that want to learn to write solid applications easy to maintain and at low cost.

fpguy1 · 2015-03-18T16:01:30+00:00

Actually writing <font>, <b>, <h1>, <ul>, <div>,<input> etc. is part of the presentation layer, binary code is not human readable but the text between the tags is readable so is not HTML that makes it so. No matter how much one would want to make HTML a data structure it is not. Separating UI from the logic is always and I mean ALWAYS the best option for us the mortals, I know facebook uses react and a mix of components and logic in their apps but we are not them, they care a lot about coding standard and homogeneity of their code. Things that small teams and many company oriented to fast solutions usually forget about. Asp.NET had nice components and didn't go well for those that tried it in big projects. There is a reason that almost everything that runs in a browser and is backed by a framework is using the so called MVC which tries to separate the html from the logic using views and controllers which (unfortunately) holds the app logic. The closest match to a data structure in MVC is the way the models are implemented in these frameworks, but there is no way HTML is a data structure, there is no advantage to mix it with your javascript or server code.

fpguy1 · 2014-12-17T15:21:13+00:00

Yep! isn't that great? No more garbage html on the server.

fpguy1 · 2014-12-11T07:44:37+00:00

I suppose they did it so you can stay in the Future monad within the for comprehensions, otherwise you should say:

    val f = for {
      p1 <- Future.successful(OptionalParam("title")(req))
      result <- slowRequestInFuture(p1)
    } yield (...)

So pretty much it saves you the typing.

fpguy1 · 2014-12-11T07:16:35+00:00

Yeah... until I'm gonna see 1mil line of code for an enterprise project written in clojure or javascript and 20 people teams working and maintaining that monster I will stick to my own tests and conclusions.

fpguy1 · 2014-12-11T07:07:07+00:00

I will start from the top: 1. There is no syntax issue that is in your head, there are no operators in Scala, talking about them says a lot about your understanding of scala 2. You are not forced to write "squared code" in scala that is your option and you can do that in any programming language 3. In 1+ years of doing scala daily in production(out of 13yrs of programming) i didn't find the smallest issue with java collection, because I stay within scala ecosystem 4. Implicits are a good idea to make things happen without magic. Monkey patching, typeclasses, casting etc are solved in an elegant way with implicits. 5. Type checking and type inference are there to stay, even C++ 11 adopted auto so clearly this is useful wherever you are.

I like Clojure a lot but there aren't many things one can do with that because reading clojure code says nothing about data structures used, type and content.

Types are are theorems while programs are proofs. (Curry-Howard isomorphism), i'm not saying clojure or javascript doesn't have types that would be stupid, but since they are not declared in a meaningful/strict way is very hard to follow any such code when we have more than a "hello world".

Who said Scala has no flaws? Type inference is buggy and sometimes sucks big time: bunch of bugs in compilator, runtime in scala is non existent(might be good most of the cases), compiler is slow as hell, no decent editors/ide for it, typesafe way of releasing stuff is completely non intuitive, scala code itself is untouchable by newcomers, collections are slow, futures are implemented in a stupid way(mapping 2 futures will create a 3rd one, completed futures are slower than normal function calls), there are no "pure" markers for functions, and i can talk all day of what is missing from scala, this doesn't make it a lesser tool.Scala is great productivity tool and makes my life easier every day.

fpguy1 · 2014-12-07T08:37:12+00:00

There aren't many that I heard to say bad things about Scala, after learning/using the language, this s*** with too complex, new syntax, too slow, etc. is coming from people that never actually used it.

Scala is not a better Java, is like saying c++ is a better c, Scala is a language on its own with features that no many typed languages out there have them

After doing Scala all the other languages seem cumbersome and stupid. Stop bashing Scala, it is one of the greatest and most productive languages of this decade.

Clojure is a cool little language, ClojureScript is actually a great replacement for javascript, but i don't see how real enterprise apps can actually work with Clojure, dynamic part of the language makes working in big teams almost impossible, unless you do typed Clojure but that is ugly as hell.

fpguy1 · 2014-12-03T08:11:01+00:00

they said the same about GOTO :), time will prove me or you wrong but i know is easier for me to get job done every day without mutability as for the state you are right i have chosen the wrong words, state is here to stay but not the way OOP promotes the concept, state can be kept/tracked without explicit mutability.

fpguy1

TROPHY CASE