41–50 of 59 posts
Tab is a statically-typed, functional, type-inferred language that occupies a niche between bash and python.
It's also not Turing-complete but can compute almost everything you could ever think of.
(I wish more languages aimed for Turing-incompleteness -- unsurprisingly, it turns out Turing-incomplete languages have big benefits for performance and resource management.)
> I strongly dislike macros that can hide in code. I get really frustrated when I open a source file and see (foo ...) and can’t tell whether it’s a function or a macro until I read documentation. Well... that's just, like, your opinion, man. Seriously though. In Elixir, for example, much of the language itself is implemented via its own macros, which demonstrates a certain nice extensibility. If Elixir followed this…
What is the need for knowing if it's a macro or not when you could just know how it works (what'll it spit out / do?)?
While I do believe in limiting stuff for the sake of simplicity, this notation will actually burden the developer into not using the macro system fully, simply because someone wants there to be a non-forced distinction between macros and other constructs in the code.
If that sort of thing interests you, also check out my language 'tab' ( https://bitbucket.org/tkatchev/tab ). Tab is a statically-typed, functional, type-inferred language that occupies a niche between bash and python. It's also not Turing-complete but can compute almost everything you could ever think of. (I wish more languages aimed for Turing-incompleteness -- unsurprisingly, it turns out Turing-incomplete languag…
Earlier quoted context omitted.
"Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string lo…
you can easily add a number to a char in C and get a jibberish character, which is why C is a weakly typed language
You can, of course, use the integer you got like a char (after all, C's char is a small integer type) to get your gibberish. You can also use a floating point number as a char, because C has lax implicit conversions.
Earlier quoted context omitted.
"Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string lo…
B and early C are untyped like this
This might seem strange, but if there's one thing from Common Lisp that should receive wider adoption in other languages, it's hyphenated names. They are so much more readable than anything else (well, C with underscores comes close).
And I agree with you that hyphens are more readable. They're also good for adding extra semantic meaning - https://news.ycombinator.com/item?id=3978992
Earlier quoted context omitted.
> the fact that you need to differentiate behavior for numbers and strings That's actually not exactly right: for example in Forth you really have no types at all. Also, if somewhat uses a word such as "unityped" or "type with infinitely many variants" you should immediately know that any mention that "there are types, alright, just checked on runtime" will be immediately rejected. Majority of static typing fanatics…
"Majority of static typing fanatics are like that." That's not the problem. The problem is that to a first approximation, every language is "type safe" in the sense that you can't add a string to a number. Even in those languages where it looks like you can, it's because of a certain usually-limited set of automatic coercions, not because you can actually add a number to a string. Truly adding a number to a string lo…
We're not discussing a concept of "type safety" here at all, but rather a concept of "untypedness". I just can't agree that for example Common Lisp (with CLOS), Smalltalk or Python are "untyped". They are not: untyped language is one which has no type errors both on compile time and runtime (unless I'm very . An obvious example is Assembler, but Forth or TCL qualify too. And quite a few others do too. See here: http://en.wikipedia.org/wiki/Programming_language#Typed_vers...
> so static typing usually refers to a language whose type system is somehow more restrictive at compile time than "Everything is a variant type and we'll work it out at runtime"
Again, it was never suggested that Tulip has "static types". It doesn't of course.
What I said is that it has types. I don't want to discuss how much better "static typing" is than "dynamic typing" or vice versa, this makes for a very boring discussion similar to Emacs vs. Vim and I'm not interested in it at all. I just object to the notion that "static types" are the only kind of types we can ever have in a language.
The problem is with "static typing fanatics", really. They'd like to bend the terminology in a way which helps them promote static typing, for example by equating all types with static types. This is both dishonest and unnecessary. No serious static typing advocate would do this (I hope) - static typing is a great idea able to defend on its own, there's no need to lie about "the other side" of the argument.
Well, all fanatics are like that. Way too much Kool-Aid, way too little critical thinking.
Earlier quoted context omitted.
you can easily add a number to a char in C and get a jibberish character, which is why C is a weakly typed language
Not true (technically). When you add an integer to a char, you get an integer. (If you add a floating point number, the result is such as well.) You can, of course, use the integer you got like a char (after all, C's char is a small integer type) to get your gibberish. You can also use a floating point number as a char, because C has lax implicit conversions.
> I strongly dislike macros that can hide in code. I get really frustrated when I open a source file and see (foo ...) and can’t tell whether it’s a function or a macro until I read documentation. Well... that's just, like, your opinion, man. Seriously though. In Elixir, for example, much of the language itself is implemented via its own macros, which demonstrates a certain nice extensibility. If Elixir followed this…
Yep, it's my opinion, and that's why I put it into the design. Lots of language design comes from opinions. I hope it's borne out. FWIW it's the same approach Rust has taken, where macros have to end with a ! to make them visually distinct.
But I can see just "knowing" at a glance if it's a macro or not.
I think the answer would basically be determined by how much of the language itself uses its own macro system AND what type of macro system it actually is. If it's significant, having special syntax would just look weird.