You're right. Those shouldn't be completely ignored. They probably shouldn't be the only argument to make tech decisions upon.
Did you ever build any webapp in Ruby on Rails? You should check it out!
Or the fact that people continue to do a lot of development in these languages would suggest that the benefits are more than marginal, and the lack of a few editor features is not such a terrible hindrance.
Strongly typed languages have a higher barrier of entry and require an engineering mindset. That's anecdotal but if I think of exceptionally competent people I've worked with on JS projects, all of them have spent time building and advocated for properly typed code bases.
The other camp "just hates it" because it "slows them down", as it seems they spend most of their time fighting the types but never get to the point where you get that huge return on investment.
I don't know, the ergonomics of the type system is not the same in all languages. A tool chain that report early useful feedbacks in a non cryptic sentences will certainly gains adoption quickly.
Unfortunately most of the time the result is at best needlessly cryptic, with zero thought about simplicity of use. Ruby has a reputation of taking care of this topic.
I've been working with types and malloc for years in C, then enter Java. No need to malloc anymore and everything worked. Great, goodbye C. Then enter Ruby, no need to write types anymore and everything worked. Great, goodbye Java.
That's the great picture. Looking into the details I've been working with Perl, JavaScript, Python plus many other less common languages. I always had a preference for languages that hide complexity away from me.
Code completion really doesn't matter much to me. I've been working for maybe ten years with an emacs package that remembered words and attempted to autocomplete with the most used suffix. It worked surprisingly well.
In my professional experience, types are a godsend for large, and/or long-running projects that have been worked on by many people over the years. They reduce complexity by informing you up-front of the shape of the data and/or objects that a function demands and produces.
If the type-checking system is decent, they also automatically catch a whole class of problems that will only show up at runtime, and may take years to surface. (Ask me about the error-handing code that detonated because it contained a typo in a Ruby class name, which was only discovered three years after it was introduced... when that code was actually exercised during an... exciting outage of a system it depended on.)
> types are a godsend for large, and/or long-running projects
Agreed. But that doesn't mean that every language needs to be statically-typed, which seems to be where we're heading nowadays.
IMO large and/or long-running projects should be written in languages with sound static type systems, not scripting languages with types tacked on. Conversely, I often work on projects which are neither large nor long-running - for those, a dynamically-typed scripting language works perfectly well.
> a typo in a Ruby class name, which was only discovered three years after it was introduced
So the code containing this typo was never tested? That's asking for trouble even if you have static typing.
> So the code containing this typo was never tested?
The code absolutely was tested. However, (obviously) not every possible path through the code was tested.
Given a long-enough timeline, you will NEVER remember to test every little thing. Given sufficient code complexity, it can be next to impossible to actually exercise every code path with hand-written tests.
That's one of the troubles with large projects written scripting languages like Ruby... you have to write an assload of tests to replace what you get for free in languages (even "loosely"-typed languages like Erlang) that have pre-runtime type-checking (whether or not it's provided by a compiler).
> Conversely, I often work on projects which are neither large nor long-running - for those, a dynamically-typed scripting language works perfectly well.
Oh yeah, for small things such languages are A-OK. I 1000% agree with that. The big problem (that you may never encounter because I bet that you're smarter than the average unending parade of Project Managers) is how often small projects are forced into becoming big projects, and then huge projects as time goes on.
I’d add to this that there’s a good reason the testing culture is so strong in ruby: you absolutely need to write tests for every last little 2-line method to make sure you did it right. With no compilation or type checking step, there’s no other way to know if your code is even valid.
Which means that IME a huge number of tests in my ruby code were doing things that a type checker does automatically: make sure that passing nil makes it return nil, making sure that passing an array does the right thing vs a string, etc etc etc.
I have very vivid memories of working in a large rails code base and having no idea whether my change would work until I actually exercised the code and realized I was completely messing up the contract that some method expected, so I had to slow down and write tests to validate my assumptions.
Fast forward to now, I work in a large Rust code base, and it seems like 99% of the time, if my code compiles, it works flawlessly the first time. So I concentrate on writing integration/functional tests, which give me a lot more bang for my buck than having to write hundreds of little unit tests. (I still write some unit tests, but the need for it is much less… the vast majority of things you’d write tests for in Ruby are things the type and borrow checkers handle for you in Rust.)
> ...there’s a good reason the testing culture is so strong in ruby:
"Strong" as in "You easily burn 10x more time writing tests as you do code... and not because it's difficult to think through how to write good tests"? If so, yes.
"Good"? Hell, no! That's a bad reason.
> ...a huge number of tests in my ruby code were doing things that a type checker does automatically...
The folks I work with demand that we don't write these tests, so they don't get written. Guess how often code detonates in production because of things a typechecker would have caught... despite the enormous volume of test code.
To be crystal clear, I totally agree with your statements in this comment. I started my "career" with C++ and I'm so damn glad I did. Had I started with Ruby and Rails, I would have come to the conclusion I was far too damn stupid for this field and left to become a lawyer.
“Good” in this context didn’t mean “this is a good situation”, but rather “if you’re using ruby, it would be very bad if you didn’t write tests”, and “bad if you don’t” can be roughly reworded as “good if you do”, at least if we’re presupposing that you have to be writing Ruby.
> In another layer of the partnership, Khan Academy will help Microsoft train an open source version of the latter's new small language model (SLM), Phi-3, with the goal of creating an AI math tutor for students
>To that end, Khan Academy will give Microsoft access to its math-related data, including math problems with step-by-step solutions. Data from Khan Academy users will not be part of the training data, the companies said.
I've been at my current role for almost 7 years. Many of the best lessons I've learned have come from the pain of maintaining and fixing my own mistakes.
Sometimes it can take 2 years just to tell if a decision you made was good or not.
It’s funny you mention Witcher 3 as an example of boring side quests when it would be my example for one case where they are actually good and is the only open world game I’ve finished since Morrowind
Is it worth playing? I've picked it up several times and tried to play it for a couple hours, but the skills and spells systems seem so limited and console-like, kinda like how simple Skyrim is compared to Morrowind.
Does it get more involved and customizable later on?
I tried with the query “principal software engineer”
Keywords were not helpful and included company names
For example:
One of the keywords was “fidelity”
Another keyword was “using”
A third keyword was “disability”
As far as requirements - some of the items on the list were actually requirements but others were just descriptions of specific companies and some were fragments of sentences that made no sense out of context
For example:
> This is a great time to join us and be part of this journey!Certifications:Company OverviewFidelity Investments is a privately held company with a mission to strengthen the financial well-being of our clients
> It also guarantees that your data security strategy adheres to compliance and data privacy regulations
Finally the list of requirements was very long - I’d expect the 10,000 foot view to be summarized a lot more - this seemed like it might be the same as skimming the 22 job descriptions it was generated from
So imo you’ve got some work to do before this is ready for prime time
First of all thank you for taking the time and sharing your experience.
> 10,000 foot view to be summarized a lot more
This is so spot on and point taken. The idea at the results page was to have filters to allow users reduce the amount of results shown. But, yes you are right the requirements list returns `one mighty scroll`. I will have a think of ways to tame it.
> fidelity
I had mixed results for company recognition from a NER perspective, and this keyword I am afraid is the product of that. I have some ways to reduce reliance on NER here, will see if that fixes it.
> disability
these type of words are slightly more nuanced as in some cases these will be relevant keywords... this I will have to iterate more.
> sentence samples
I expect the model to get better over time to weed these out. I am somewhat weirdly confident about it as I have seen 1st hand how it missed obvious things in earlier versions, but is doing much better now.
all in all thank you once again for taking the time, have a great day.
I always learned y was sometimes a vowel and some googling after your question led me onto the fact that W is sometimes considered a vowel as well - though the only examples I’ve found are welsh loan words like “cwm”
reply