I had an idea years ago when I still had the young man’s dream about writing a programming language. It came after I took over a J2ME project that was trying to do a great deal of functionality in an 85K jarfile.
That idea was that there should be a little language inside of each big language that is used to implement the self hosting aspects of the language, and then a small set of additional libraries would provide a usable embedded variant of the ecosystem, good for small places and things that have to start quickly.
I like this idea. I believe Rust does something somewhat similar (though not quite) for processing compile-time procedural macros. We see somewhat similar, but external approaches in the Clojure ecosystem with Babashka and Joker (and probably a few others).
In general, I like this, but not every language actually needs it. Like, what would that even be in Python for example?
Something for PyPy perhaps? JITs written in the host language are the original use case I was thinking of, but that’s not the sole domain where it applies.
"This brings another discussion point: a type system naturally restricts the amount of code we can write because, in order to prove certain properties about our code, certain styles have to be rejected."
I can't but think few things:
- by compilers (in this case static type checkers) laws we all know that there are valid programs that won't satisfy the type checker and viceversa there's only a handful (none being production or development ready) of compilers powerful enough to infer all code bugs
- limiting the expressiveness of a language isn't necessarily a bad thing
I've noticed that people with a huge background in dynamic languages tend to have a natural refusal for static types. Lispers are a community with such an attitude, even the typed lisps like typed/racket seem to be born more to please people wanting typecheckers and academics than the userbase itself.
But I, and my mind, work the other way around: I want to think about the types first, I need them to express my domain and my DSLs, so I need an expressive type system able to translate my thoughts and validate all of my program with nothing but types. It's possible in plenty of languages (most famous one is TypeScript with its declare keyword) to do type-driven development and I can't really function without it.
Once a program has been well modeled, once I've seen the APIs, then and only then I get into implementation and it is by far the part I spend less time on.
Every time I read a lisp dialect without static types (most of them) my mind just doesn't work properly, I can't follow much. And I really believe that the lack of commercial success for many of these languages derives from how poorly non statically-typed languages scale when klocs and number of maintainers of a project start increasing.
The main question of the quote is: if we introduce a system that rejects a "large" amount of Elixir code, will developers adopt it? If some language features are only available for "untyped" code, will developers often forego types only to get those features? And if that happens, could we end-up "forking" the Elixir community, where part of the community uses some idioms and the other part uses others (which is a common complaint about large languages)?
The goal is not to reject types but rather to find a theory that mirrors the language as close as possible. I believe balancing these trade-offs will be essential to the adoption and success of a type system in Elixir.
I use Elixir whenever I can, and I would love a better type system (though I admittedly suck at using what Dialyzer already provides, which is extensive). I'm very excited to see where the current effort goes!
But absolutely, if new types break existing Elixir code and idioms it would result in a schism that would be devastating and disastrous to the Elixir community. I for one am really glad you are asking these questions, and FWIW I think you're doing exactly the right thing.
> I've noticed that people with a huge background in dynamic languages tend to have a natural refusal for static types. Lispers are a community with such an attitude, even the typed lisps like typed/racket seem to be born more to please people wanting typecheckers and academics than the userbase itself.
I feel like it's the opposite. It seems like we have this huge wave of a push for static types. The only way I can explain it to myself is that a bunch of people using dynamically typed languages finally came over to the static typing side. And I say this as someone that worked using statically typed languages for pretty much all of their career.
I get it for TypeScript and the frontend. The frontend is a huge, complex mess of interactions, in the same codebase. Static types are awesome there.
But the way we write most backend systems these days, IMHO, static types are practically a nothingburger. Sure, they were awesome when I was working on those millions of LOC projects back in the 2000s. But nowadays those millions of locs are spread across N projects which are separated by a typeless network boundary so I'm not looking at anything more than 50-100k LOC anyways.
So I just don't get it. Systems are written in a way that devalues static typing, but it feels like the demand for it is higher than ever.
As someone maintaining a moderately complex codebase in Python: static typing doesn't feel valuable until you need it. But then you really, really need it. Thank god for Mypy and type-hints.
I'd prefer something that can infer types in the simple case and have explicit types when dealing with huge complexity. Really, it comes down to having tight control around the shapes of your data, and that is incredibly valuable when you cannot keep the entire codebase/API/contract in your head. Quick navigation is a huge bonus too.
I also don't fully understand it. Maybe it's driven more by the ease of autosuggesting/completing in static typed languages than actually catching bugs. It will swing back like everything else and reorient on slightly different direction. This pendulum is quite slow though.
It's not satisfying to everyone, but if lack of types is hampering your desire to learn Elixir, check out Dialyzer[1]. It's certainly not perfect, but between pattern matching struct arguments and Dialyzer, I've yet to personally encounter a situation where it wasn't sufficient.
Programs never have to be rejected; programs can be diagnosed (so we are informed) and run anyway.
Programs have to be rejected if there is no safe way to handle them at run-time, when for the sake of efficiency we removed the type bits from the data. (And not even always then; the programmer may have assured safety otherwise.)
Yes, but there’s a PhD student working with Jose on this and I think the timeline was 18 months. My guess is it’s a joke around how stable everything in the Elixir world remains compared to other constantly evolving ecosystems.
Also meta has a static typing system for Erlang. Also, dialyzer exists. So if it's "never" he means set theoreic types, but there are incomplete set theoretic type libraries for elixir
I had actually started typing Facebook, then remembered that it was Whatsapp, which post name change is technically not Facebook but actually meta, so I submitted as meta for correctness
Do you need to have static typing in your byte code for static typing at the language level to be useful?
I ask because the JVM lacks static typing[1] at byte code level but Java and Scala have it at the language level where it seems to be useful for correctness and performance.
the compiler can type check source code for any obvious insanities, and thereby catch and prevent, at compile time, a subset of what would be runtime errors.
that's the idea anyway. (i worked on v8 for example, and other compilers, and typescript does something similar targeting javascript)
If you have built a program in any other language I would say rewrite that program in GO. The benefit being you already solved the the domain logic of the program the only thing you need to focus on is writing/learning GO.
If this is your first programming language or attempt to learn to program I would say to just pick a small but simple app/program and just go ahead and build it. Don't spend too much time on reading articles or video tutorials just get your hands dirty as soon as possible.
How's your experience using flutter web? I love flutter and dart used it for a few mobile apps. Tried using Flutter Web and felt like it was missing a lot to make it usable in production.
I haven't used it yet, actually. I'm hoping that it's good enough for what I'm doing (which is more or less just a fancy CRUD app), but if it's not, then I can always wait on the web app until it's ready.
FullStack developer focusing on building backend APIs and SPA/PWA front ends. Currently a lead developer at venuegenie.com with plenty of startup and agency experience. Even if the position doesn't hit one of my strengths don't be afraid to reach out I'm always open to learning something new.
"The addition of Alford, an African-American woman, comes as Facebook and other Silicon Valley companies strive for the inclusion of more women and minorities in their boards and throughout their workforces."
Honest note why do they have to add she's an African-American woman it just makes it seem the only reason she was hired was because she was a minority and not do to her skill set.
"The law, signed by Gov. Jerry Brown on Sunday, requires public companies whose principal executive offices are located in California to comply by the end of 2019. The minimum is two female directors if the company has five directors on its board, or three women if it has seven directors by the close of 2021." NPR, Oct 1, 2018 [1]
1. because the rest of that sentence/statement wouldn't make much sense without the context
2. because it's newsworthy: historically african americans and women have been excluded from boards. So as the trend begins to shift, this happening is, as an outlier event, newsworthy
3. because having diverse views and voices at the table is better for solving problems. Since business is fundamentally about solving customer problems, it is noteworthy to highlight the swap (african american woman replaces european american man)
If you read the article... It's clear that the author agrees with your statement that the most noteworthy thing about her is her ethnicity and her gender.
>The addition of Alford, an African-American woman, comes as Facebook and other Silicon Valley companies strive for the inclusion of more women and minorities in their boards and throughout their workforces.
That doesn't make it true, but it exactly what the author is intending to point out.
The honest answer is that you can't know whether they're trying to implicitly point out that she was only hired for her race or whether they're trying to hold her up as a hero of the black community.
I would like more open discussion between people at the very least. I think large news outlets simply have to do a better job at taking advantage of their outreach and giving proper visibility into people like her when they're finally given their chance to be in the spotlight. She may be the least famous person in the article but she is his replacement and their coverage of her merits is laughable at best. Any other mention of her in this story is strictly filler. Just give her more than dropping her current title and that cringy statement. Improper coverage like this happens too often and needs to be pointed out so that it bad attention when it is published.
I understand that a segment of society descends into conspiracy theory when reading an article but perhaps you might consider whether noting that Alford is an African-American woman gives further context or is contrasted with the noting of SV's apparent push for demographic diversity.
No doubt that she's a talented woman, but I'm guessing her minority status is the primary reason for her being chosen. Does anyone really believe that they were looking for the most skilled person for this position, and it just conveniently happened to be an African American woman? I'd want to believe that but I would just be lying to myself.
Perhaps she was hired for her skillset as well as being African American. If you are trying to include more minorities in your workforce then having a person from those minorities will have perspectives that people who are not from those minorities will not have.
Just make sure she's not a conservative A-A (like Kay Coles James) who was appointed to Google's AI oversight board, who happened to be conservative so got booed out. Such a sad state of things. [Most women independent of political affiliation applauded the appointment]
It's obviously not about being a woman or being African American/Black. They just cannot be conservative (or liberal-democrat).
Web components are awesome I've been using them in production using StencilJS for a pretty large app for about a year now. Even though browser support is widely available there are still a few gotchas with web components, specially Shadow DOM. Not all community tools have caught up as well. For example you can't use Stripe v3 with Shadow DOM. Most analytics tools also cannot access the Shadow DOM. We had to remove Shadow DOM from all our components that were using it. In my opinion Web Components are definitely the future but there's still some catching up to do before we can claim it can replace frameworks.
Thanks I had actually seen this while looking into a workaround for us. However I thought that LitHTML elements only worked with other LitHTML elements since you need the correct bundler for it. StencilJS projects don't have any bundling system.
