Microsoft has signed an agreement to acquire Xamarin, a leading platform provider for mobile app development:
In conjunction with Visual Studio, Xamarin provides a rich mobile development offering that enables developers to build mobile apps using C# and deliver fully native mobile app experiences to all major devices – including iOS, Android, and Windows. Xamarin's approach enables developers to take advantage of the productivity and power of .NET to build mobile apps, and to use C# to write to the full set of native APIs and mobile capabilities provided by each device platform. This enables developers to easily share common app code across their iOS, Android and Windows apps while still delivering fully native experiences for each of the platforms. Xamarin's unique solution has fueled amazing growth for more than four years.
[...] Through Xamarin Test Cloud, all types of mobile developers—C#, Objective-C, Java and hybrid app builders —can also test and improve the quality of apps using thousands of cloud-hosted phones and devices. Xamarin was recently named one of the top startups that help run the Internet.
I have heard of Xamarin, but have no experience using their products. I have experience MANY years ago with tools that aimed to provide native-like appearance and actions with a common code base, but they always seemed to come up short. How well does Xamarin's products/tools hold up?
(Score: 2) by mendax on Thursday February 25 2016, @01:23AM
I like Mono. I learned C# using Mono on a Mac (and then promptly forgot it all) but I came to respect it. Somehow, now that Microsoft is buying Xamarin I'm afraid Mono will wither on the vine. Yes, Microsoft has published the specs to its .NET infrastructure and apparently is actually writing its version of .NET to the specs, but with Xamarin there seems to be no incentive to continue to support it.
It's really quite a simple choice: Life, Death, or Los Angeles.
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @01:32AM
Are you talking about the "root" language, or the API's and UI frameworks? It looks like Xamarin supports C# as an option for a base language, but the Dot-Net related API's and UI framework(s) and conventions may all be changed or go away. This is normal, as UI conventions and fads change like the wind.
(Score: 5, Informative) by stormreaver on Thursday February 25 2016, @02:10AM
Somehow, now that Microsoft is buying Xamarin I'm afraid Mono will wither on the vine.
That would be the best possible outcome, as Mono is a lock-in disease that needs to be eradicated.
(Score: 2) by Common Joe on Thursday February 25 2016, @05:01AM
With C# / Mono controlled by Microsoft and Java controlled by Oracle, what cross-OS, mature languages would you recommend to replace them that is well used, well supported, and can help put food on the table?
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @05:22AM
Time to revive Pascal?
(Score: 3, Insightful) by Common Joe on Thursday February 25 2016, @06:51AM
I'm sure this is tongue-in-cheek. In all seriousness, I maybe should have mentioned that the libraries are just as important (more important?) as the language. I don't know anything about today's Pascal, but I'm guessing it wouldn't fit what I'm looking for because the libraries to support it would be weak. Another important item: being able to learn how to use the language in a safe, secure, and easy way. There are way too many insecure examples floating around for Java, C#, and web languages these days.
(Score: 0) by Anonymous Coward on Monday March 07 2016, @05:35AM
It would still need an intermediate language to native-compile from, but it actually has a comprehensive ecosystem of libraries, a huge amount of cross platform compatibilty, support for everything from dos to windows to osx to linux. Hardward support from the 90s to today, and support for Delphi and/or limited Objective Pascal, depending on what programming model you prefer.
I haven't done as much with it as I would like, but I see no reason it couldn't return to prominence for application level programming.
(Score: 2) by maxwell demon on Thursday February 25 2016, @07:42AM
What about Python?
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Common Joe on Thursday February 25 2016, @11:14AM
I actually looked into that for a bit, but came away disappointed. The libraries are pretty decent and it's well supported, but I find the language itself is immature. The variables do not have to be declared; it is not a strongly typed language. Yes, there is an add-on that can do that, but it should be built into the language. (I'll acknowledge that a weakly typed language is useful too. In my opinion, both weak and strongly typed options should be baked into the language specification and allow the programmer to chose one at compile / run time. C# and Java are both strongly typed and are missing the weakly typed option, so they have this problem too, but from the opposite point of view.) Given a choice for major projects, though, I want a strongly typed language. At its heart, Python is a scripting language. I also don't like the scoping of the variables in Python. There are times when I want a variable to be only internal and not publicly accessible. Python is a little too loose on that front.
To me, it seems Python is next after C# and Java as far as flexibility and usability, but I wanted to hear what others' opinions were. I acknowledge that I'm not always right nor the most knowledgeable in all programming matters.
(Score: 2, Informative) by Anonymous Coward on Thursday February 25 2016, @03:20PM
Incorrect, Python is a strongly typed language. It is certainly not statically typed, however.
(Score: 2) by Common Joe on Thursday February 25 2016, @03:59PM
AC, you are correct [python.org].
With that said, I prefer statically typed languages over dynamic / strongly typed languages. But, on the plus side, you've given me something new to chew on.
(Score: 2) by Pino P on Thursday February 25 2016, @09:54PM
You are confusing the axis of weakly typed vs. strongly typed with the largely orthogonal axis of dynamically typed vs. statically typed. Python is strongly but dynamically typed [python.org]. It's strongly typed because 1 + "2" raises a TypeError rather than returning 3 or "12". But it's dynamically typed in that values have types, not variables, except for elements of specialized array types (such as bytearray, array.array, and arrays provided by extensions such as numpy.array).
(Score: 2) by Pino P on Thursday February 25 2016, @09:48PM
Say I am about to write a GUI application in Python. Which GUI toolkit should I use? I've read horror stories about deploying PyGTK 3 to Windows.
(Score: 1) by Deeo Kain on Thursday February 25 2016, @09:32AM
C, C++ of course.
(Score: 2) by Common Joe on Thursday February 25 2016, @12:08PM
The languages C and C++ are not really cross-OS languages. The libraries are definitely not. I'm not really familiar with QT, so that might be an option, but even if that is fully cross compatible, you're gambling your company on the success of another company. (I suppose the same argument could be made with Microsoft / Apple. But at least with a language like Java, one could argue that there is more than on compiler in every OS.)
What's your opinion on QT? Or did you have something else in mind?
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @04:28PM
But at least with a language like Java, one could argue that desktop programs on it are bloated slow crapware.
(Score: 3, Interesting) by Marand on Thursday February 25 2016, @02:29PM
It's kind of an odd duck, but what about Clojure? It's a lisp that targets the JVM, but there's also support for running it on the CLR (.NET) instead, and there's also an official variant called ClojureScript that targets JavaScript in the same way. It provides ways to interact with whichever platform it runs on so you still have access to the underlying platform's features along with whatever mature libraries you want to use.
Any Clojure code will work on any of the targets, though obviously the JVM/CLR/JS interop is platform-specific. Still, if set up correctly, most of your code will work on any of the three; they even added a feature somewhat recently to help simplify that sort of multi-targeting.
It will seem pretty alien at a glance, though; in addition to lisp syntax, it strongly encourages (without outright forcing) functional programming, and likewise encourages the programmer to avoid mutable state and side effects where possible through language design. It's not as ham-fisted about it as Haskell, though; you can still make mutable bindings, throw side effects in anywhere you want, and even kludge your way to imperative programming if you really want.
A lot of the design decisions are newer ideas, aimed at reducing or eliminating common bugs and making concurrent and parallel programming easier for the programmer so you can more easily use multiple cores safely. For example, you can have different variable types that follow different models with regard to threading. Vars give you thread-local bindings, atoms work more or less like normal variables, refs implement a transaction model similar to how databases work, and agents are vaguely like actors (but not quite). They have diferent behaviour regarding threading and concurrent access, so you can choose the one that works the way you need and avoid having to deal with locks yourself.
This talk [infoq.com] by Clojure's creator, Rich Hickey (transcript [github.com]), covers a lot of the logic behind the language design. It's not a Clojure-specific talk, but he explains concepts that are core to the Clojure design, and why they're chosen. Gives some insight into why the language uses software transactional memory and encourages immutability and pure functions.
Anyway, like I said, it's not necessarily going to be for everybody, but it's an interesting language with well-thought design, easy syntax (nothing is simpler than a Lisp), and it's usable just about anywhere thanks to the JVM/CLR/JS targeting.
If you just want to play around with it, there's an online Clojure instaREPL [clojurerepl.com] that is basically a web-based version of LightTable's inline evaluation, using ClojureScript. There's also a more traditional REPL [herokuapp.com] that's similar to the command-line REPL, too. For local use, running it on the JVM is as simple as downloading a .jar and running it like any other Java app, and it's probably similarly easy with the CLR. Using ClojureScript is a bit more involved I believe, but not sure.
Related but not actually Clojure itself, there's also a (very new) language called Pixie [pixielang.org] that is basically a scripting-oriented Clojure. I've been using it for shell scripting type stuff lately because JVM+Clojure startup time is fine for applications and long-running tasks but not so great for quick-running script type stuff. It's a Clojure-alike for places where you'd normally pull out Perl or Python.
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @07:24PM
The marketplace pretty much wants an Algol-style language (if/while/function blocks) and is not so keen to go heavy functional. Whether they "should" is a long and winding debate I won't get into here. In part because having plug-swappable coders is more important to biz than highly-factored code and optimized symbolic abstraction. The second requires a higher caliber of staff. Lisp variations will be rejected for mainstream.
OSS software offers plenty of dynamic language choices, such as Python, Ruby, and Php; but not many static languages of the C#, Java, and Ada kind.
(Score: 2) by Marand on Friday February 26 2016, @01:06AM
The marketplace pretty much wants an Algol-style language (if/while/function blocks) and is not so keen to go heavy functional. Whether they "should" is a long and winding debate I won't get into here. In part because having plug-swappable coders is more important to biz than highly-factored code and optimized symbolic abstraction. The second requires a higher caliber of staff. Lisp variations will be rejected for mainstream.
Functional programming's been seeing a surge of interest lately, probably because per-core performance is stalling so workloads need to go multi-core to use the power available. It remains to be seen, but it's possible that the need for better use of concurrency may end up making FP the next big "everything must be $FOO" like OOP has been for the past couple decades. However, you're completely right about the algol thing, unfortunately. Though Clojure does provide a lot of options for that style when needed, the syntax is still lisp-y and that tends to put people off for some reason. It's a shame, because lisp syntax is incredibly unambiguous and you can do so much with the macros it enables.
Though, Clojure's been doing much better for mainstream acceptance than the traditional lisps (CL and Scheme) for some reason. Not sure if it's the focus on concurrency or its use of the JVM giving you a compelling Java alternative that can still use the expansive Java API, but it's thriving in a way lisps historically have not. Hopefully it continues to do so, but even if not maybe it will help popularise some of the nice things it implements. STM, immutable data, etc. aren't new ideas, but a language that implements them gaining traction is pretty new.
OSS software offers plenty of dynamic language choices, such as Python, Ruby, and Php; but not many static languages of the C#, Java, and Ada kind.
Probably because there's already C, C++, C#, Java, and Ada. Java's reference implementation is OpenJDK (which is GPL), Ada is standardised (multiple ISO standards and an IEEE one), and of course C/C++ are likewise are likewise standardised. Trying to make a new one doesn't go anywhere because it just brings out the C/C++/Java crowd to bitch about how it's not C/C++/Java, like with Rust.
Also, dynamic probably is just more interesting to people making new languages. It's not a small task, so if you're making a new language, you likely either want to make something that will save you work down the road, or you want to do something that existing languages you like don't do. That will inevitably lead you toward making higher level languages that do more for you rather than making a thin wrapper around assembly.
My preference seems to be for strongly-typed, dynamic languages. I don't mind dynamic typing but still prefer strong typing vs weak (though they're really loosely defined so eh, not really a lot of room for discussion there)
(Score: 0) by Anonymous Coward on Monday February 29 2016, @05:03PM
Not for the vast majority of programming actually done. Unless you are doing something wrong, processors are usually sufficient as they are. The bottlenecks are usually the network, the database, or bad design. (Databases can already take advantage of parallelism without explicit parallel programming.)
See Great Lisp War: http://c2.com/cgi/wiki?GreatLispWar [c2.com]
C/C++ are generally consider too low-level for common application-level development (excludes graphic-intensive, OS, drivers, and database engines, for example). Ada is considered too complicated by the market-place (I'm just the messenger), and Java and C# are still too much in the grip of companies who lost credibility. Nobody trusts them to not play games with the languages for short-term profits.
The gap still exists; those don't solve it.
What's needed is a statically-typed language similar to Java and C# that has no ties to any private organization.
Perhaps, but that's not solving the gap in product choices. I have my personal preferences also, but the marketplace doesn't care about my preferences nor yours. It wants a "non-weird" modern statically-typed language that is not at the mercy of greedy company.
(Score: 2) by Marand on Monday February 29 2016, @08:08PM
I really don't have much to say about your response, but didn't want to just ignore it. I was speculating on the recent interest in FP and possible reason for it, not trying to say it was definitely going to be the next big thing. If FP is something that interests you, though, it seems like it's a good time for it.
Also, the stuff I mentioned may not fill that gap in your opinion, but what does? Not just FOSS, but in general. It seems like nobody really wants that middle ground except the people already using C# and Java, and they already have C# and Java. I know it's cool to hate Oracle (I do too) but Java isn't just them, so it's probably safer than C# at this point.
Though, I think the benefit of those languages isn't so much the language as the platform, and for better or worse, it's looking like if you want something like that, you target .NET or the JVM, and that's how it's going to remain for now. Unless you count Javascript, I guess. (I don't.)
(Score: 0) by Anonymous Coward on Monday February 29 2016, @08:41PM
What I believe the market "wants" is a statically-typed language similar to Java and C# that has NO CONNECTIONS to corporations with suspect reputations per OSS. (Ideally no connections to ANY corporation, but that may not be realistic.)
We have plenty of non-corporate-tied "Algol-family-influenced" dynamic languages to choose from, but almost no equivalent static ones with sufficient traction.
There's an OSS itch to be scratched. It would generally have:
1. Static typing
2. C-like syntax (not my fav, but the marketplace likes it. I like the type name after var name)
3. OOP built-in rather than an after-thought.
4. Naming spaces/conventions conducive to large applications
5. Automatic garbage collection
Whether it's compiled into EXE's or on a virtual machine is secondary. Ideally it'd offer both options. VM's have sucked security-wise.
(Score: 2) by Marand on Tuesday March 01 2016, @01:40AM
It sounds like what you want is basically D [wikipedia.org]. Though judging by its failure to catch on, I'm not sure claiming it's what the "market wants" is an accurate assessment. Everyone would rather just stick with C++ or Java.
Still, it seems to meet your requirements. It's a C-successor, OOP built in, static typing, namespaces, garbage collected, and also sports type inference and some functional niceties as a bonus. The only thing it might fail is the "no corporate connections" requirement, depending on how stringently you enforce that; it's tied to an individual (Walter Bright) and his own business. I've messed with it a bit in the past and liked it more than C++ or Java overall, but never really used it for anything important. Still, give it a look if you haven't.
(Score: 3, Interesting) by Common Joe on Monday February 29 2016, @06:51AM
I wanted to have time to look at Clojure before responding. My take? I'm not a big fan of the syntax. It reminds me of when I studied Scheme back at the university. (Go figure. They're both functional languages.) One of the problems I have is the amount of indention and inability to see which open parenthesis goes with which closed parenthesis.
Maybe I'm just old fashioned that way, but I can say that I like Python's indented way to do things -- less brackets. Which is interesting since I tend to like the curly bracket usage for syntax.
I'm also a little suspicious of how heavy Closure relies on Java libraries as, I feel, that means it relies on Oracle guiding the direction of Clojure to a certain degree. It isn't just about the syntax, but also the libraries.
Maybe in time, I'll learn to appreciate the language, but for now it seems... I don't know... like a forced syntax? It's hard to describe. Maybe it's just personal preference and there is nothing wrong with the language, but gut feeling tells me the number of parenthesis and indentions can make it too hard to read in some circumstances.
(Score: 4, Informative) by Marand on Tuesday March 01 2016, @12:27AM
A lot of what you're saying mirrors my initial reaction to it until I sat down and started spending time with it in earnest. I've come to like lisps since, but really, the only reason I even gave Clojure a shot was I wanted something that could target Android and was getting frustrated with everything else I tried. I started realising I actually like functional style and a lot of it mirrors how I already liked to do things in other languages, so I gave it some more time and got used to the lisp-y nature. So, what follows are some thoughts on your impressions.
Maybe I'm just old fashioned that way, but I can say that I like Python's indented way to do things -- less brackets. Which is interesting since I tend to like the curly bracket usage for syntax.
I used to strictly prefer the curly brace style but over time started leaning more toward alternate ways of defining blocks, like how Ruby uses "do" and "end" instead. I touch-type so I find it easier to type and no worse to read (maybe better, not sure). I like how Python looks but don't like using whitespace as the way to mark the nesting. It removes flexibility and introduces new potential for errors.
What I've noticed with lisp syntax (at least Clojure's variety of it) is that I read it in a similar way to Python, but the parentheses mean I can choose how the indentation works instead of being forced to do it Python's way. The parentheses are like grouping in math, you use them to mark beginning and end of a thing. That's all. Past that, you're free to nest as much or as little as you want, or indent how you like. I find you still read the code by the indentation and end up just ignoring the parentheses. They're there to tell the compiler what you want unambiguously while letting you do what you like.
Another thing to note is when you say "gut feeling tells me the number of parenthesis and indentions can make it too hard to read in some circumstances" that's as much an indication that you could refactor the code differently. In the same way that nesting if-else statements many levels deep is a "code smell" indicating you should probably look into refactoring, you see the same sort of thing with deep nesting of lisp forms.
Clojure and some other lisps even have things in place to simplify that. Clojure, specifically, has an arrow macro (->) that lets you describe a deep nesting as a chain instead. So instead of a heavy nesting, such as (print (baz (bar (foo "string")))), you can do this:
(-> "string"
foo
bar
baz
print)
You also can use "let" to set temporary bindings, which can also be more readable. Set up a bunch of temporary bindings in a let and then use them inside instead of a deeply nested pile of functions. They're all valid ways to solve a problem, you just have to figure out what works for you. It's also a common suggestion that, if you have many levels of nesting in a function, you should break some of it out into a new function and call that instead. Especially when it can give you a reusable function that could be useful elsewhere.
I'm also a little suspicious of how heavy Closure relies on Java libraries as, I feel, that means it relies on Oracle guiding the direction of Clojure to a certain degree. It isn't just about the syntax, but also the libraries.
It's not so much reliance on Java as not reinventing the wheel. Clojure itself doesn't reimplement everything, though it does often provide Clojure-ish interfaces to the underlying bits for common things. Meaning that it doesn't try to recreate every string, date, etc. class and method, instead providing a way to interact with them when you need. That lets you take full advantage of the parent platform and its libraries (whether it's the JVM, the CLR, or JavaScript) where necessary, though the way it provides the interop lets you generally handle it in a Clojure-ish way.
That doesn't mean it's tied to Oracle and any Java meddling, though. As far as I'm aware, the only parts of it that are implemented in the parent language (Java, C#, JavaScript) are the parts that must be to get the reader and necessary abstractions like sequences running. Past that, Clojure is implemented in Clojure, with heavy use of macros to make things fast. That means most of it ends up being the same regardless of where you run it. Oracle isn't dictating its direction any more than Microsoft is. It's just a platform to run it and libs to use.
Though, don't let that discourage you. If targeting the JVM is a no-go, there's always the CLR (not that I'd say that's a better situation) or you can use ClojureScript instead, which compiles Clojure to JavaScript and the interop function is used to call Javascript instead. Hell, you can even use cljs to make native apps if you want; LightTable works like that. Or you can mess with Pixie, which I mentioned already. It's not proper Clojure (and lacks some of the cool things like STM currently) but it's close, and it's built with Python but runs on its own VM. Uses a foreign function interface to interact with C libs instead. Might be a place to start while deciding if you like it enough to mess with the real thing, I guess.
(Score: 2) by Common Joe on Tuesday March 01 2016, @04:57AM
I've given both of your comments informative points. Wish I could have given you more as you wrote a lot of great information and gave me a lot of what I wanted to know.
Clojure sounds better than I feared, but the reasons why are because it pushes away from a functional style and more towards a imperative / OOP style in certain circumstances. I think as I learn more, I'm understanding that mixing the three styles can be an advantage and most functional languages allow for this. It is possible to force imperative / OOP languages into a sort-of-functional style, but the syntax isn't designed for it and it comes out funky. My biggest concern about mixing the three styles is that programmers who don't adapt well to the strict styles (like newbies) cause a lot of confusion and bugs.
I've used a lot of languages over the years. Using "do" and "end" kind of syntax to determine blocks is fine and works well. I actually learned programming on BASIC with line numbers before moving to the versions without. When I realized that one didn't need line number and could use the do-end kind of blocks, my ability to program jumped miles ahead of where I'd been. The reason I prefer curly braces these days is because the curly brace symbol jumps out as a "begin" and "end". The characters aren't used anywhere else in the language and it just screams in my mind not only as an open / close, but also as a warning for scoping issues. If the indentions don't match the braces precisely, I tread very carefully through the code. Do and end offer similar protection, but without as much screaming in my head.
Thanks again for such an informative write-up. Clojure sounds much more appealing.
(Score: 3, Informative) by Marand on Tuesday March 01 2016, @11:10PM
I've given both of your comments informative points. Wish I could have given you more as you wrote a lot of great information and gave me a lot of what I wanted to know.
I just figured since you were seriously evaluating languages I'd try to give useful information. It can be hard to get something that isn't zealotry or flamebait trolling when discussing programming languages so I wanted to provide some extra signal to offset the usual noise. I'm still relatively new to it and, while I clearly like the language, it's not a religion for me like how some people approach lisps.
Speaking of information, if you decide to read further, so far I think Clojure Programming from O'Reilly has been the best book, though you'll probably want to try finding it on sale somewhere if you go that route. Pragmatic Bookshelf's Programming Clojure was decent as well, though I didn't like how it approached some of the concepts as much as the O'Reilly one. Not as nice, but freely available online, there's also Clojure for the Brave and True [braveclojure.com], which is a bit on the silly side but does cover some of the basic stuff...Just not as well as the other books. Still, might make a good introduction when deciding whether to pursue the language further.
Also interesting is the Clojure Cookbook [clojure-cookbook.com], another O'Reilly one. It's not a learning book, but it's interesting because the full text is hosted on Github, so you can use it to see how people solve various common problems in Clojure. The entire thing is there in asciidoc format, so you can use something like asciidoctor or a2x to create pdf, html, epub, whatever out of it for easier reading. It won't teach you Clojure, but it's nice for seeing how to do simple things that elude you, or to get a feel for how to do various things in an idiomatic way.
Clojure sounds better than I feared, but the reasons why are because it pushes away from a functional style and more towards a imperative / OOP style in certain circumstances. I think as I learn more, I'm understanding that mixing the three styles can be an advantage and most functional languages allow for this.
Yep, that's what I like, too. It's a pragmatic approach to functional programming: its designed to make doing the "right thing" easy without making non-functional impossible. Same with mutability, STM, etc. It's often easier to solve the problem functionally, but if you can't wrap your head around it you have other options, unlike strict languages like Haskell.
The other cool thing is that some of its constructs like the arrow "threading macro" I mentioned, and let, will allow you do to things in a way that looks/feels/reads more imperative but is still really FP. Like the arrow example I gave, it reads like an imperative list of things to do, but the macro expands itself into a bunch of nested forms. It's still FP despite not looking it. Likewise for let, you can do a lot of work in a let if you feel it's more readable. Here's an example from ClojureScript's source [github.com] to show what I mean; all the work's done in the let, then it just returns a hash-map of all that work at the end.
As for mixing OOP, something I've noticed is that if a language has some sort of hash-map and first-class functions (e.g. a function is like any other value, able to be passed around or stored), you can do anything OOP can do. In fact, that's how Lua's object system works: the "objects" are just tables (the only complex data structure Lua has, essentially a keyed map), and "methods" are keys that have functions as the value. Perl 5's objects are the same way, and you can do the same thing with Clojure if you want, which should cover most OOP urges. Hell, there's no reason to even go that far usually; just using hash-maps for structured data storage will likely cover most object uses without needing to create methods to go with.
Also, I guess it's because it's made to work on top of the JVM and CLR, but Clojure's really good about interop with classes. You can still extend classes, implement interfaces, create new classes, etc. just like you'd expect to do in Java.
It is possible to force imperative / OOP languages into a sort-of-functional style, but the syntax isn't designed for it and it comes out funky. My biggest concern about mixing the three styles is that programmers who don't adapt well to the strict styles (like newbies) cause a lot of confusion and bugs.
I think that sort of thing resolves itself over time. I'm still new with it myself but I find I do something, then when I'm done I go "hey, this would be better if I..." and refactor it in a more functional style. It helps that the language itself encourages the style without forcing it, because instead of just getting frustrated, I would make something that worked and realise it was ugly/clunky and immediately see how I could fix it.
An example of that is where I've been making a wrapper of sorts for Nix [nixos.org] to give me apt/git style ways to call some of the nix commands (like nix-env -qa, nix-collect-garbage, etc.). To get started, I hacked together a simple implementation that just calls the appropriate shell commands, and afterward I noticed I never used mutable state anywhere. I wasn't even trying to avoid it, it just happened naturally. If I start parsing shell output for nicer printing I might use one atom, but that seems like all I'll need.
I've used a lot of languages over the years. Using "do" and "end" kind of syntax to determine blocks is fine and works well. I actually learned programming on BASIC with line numbers before moving to the versions without. When I realized that one didn't need line number and could use the do-end kind of blocks, my ability to program jumped miles ahead of where I'd been. The reason I prefer curly braces these days is because the curly brace symbol jumps out as a "begin" and "end". The characters aren't used anywhere else in the language and it just screams in my mind not only as an open / close, but also as a warning for scoping issues. If the indentions don't match the braces precisely, I tread very carefully through the code. Do and end offer similar protection, but without as much screaming in my head.
I started there too. I grew up with access to an archiac version of BASIC (on a Tandy TRS-80) that later led to getting a hand-me-down Commodore 128D with a newer, but still line-numbered, version. Moving to something with better flow control was amazing. Of course, I ended up in Perl eventually and that completely stunted my programming forever. :)
I'm only half joking about that, actually. It spoiled me because it made a lot of things easy that were a lot harder in other languages. Stuff that I only "recently" (comparatively) discovered gets taken for granted with functional programming.
As for the braces, even with them, I usually focused more on the indentation than the braces for nesting. I like the big-picture type view of just standing back and looking at the layout for an idea of where something's wrong. You'd think I would love Python for that, but I never could get over being forced to follow the language's idea of what proper indentation is. Heh.
(Score: 2) by Common Joe on Wednesday March 02 2016, @05:27AM
Then you and I have a lot in common. I also started on the TRS-80 then moved on to the Commodore 64. For many years, I kept looking between the two computers going "How did they make sprites work!? The TRS-80 can't do anything like that!". You'll find this funny too: there was a 3D maze game on the TRS-80 (very simple, of course) that I could load up, but I wanted a game in outer space. I kept wondering how I could program that in BASIC. Being very young, not understanding anything more than simple algebra / arithmetic, or that 16K (expanded!) of RAM wasn't going to get me anywhere in the BASIC language, I tried to write my 3D space battle game. I never completed it. These days, one of my hobby projects that I pull out for amusement is a much more complicated version of that 3D game that I started envisioning all those [mumble] years ago. The TRS-80 is where I fell in love with programming.
After that, I stuck with BASIC for longer than I probably should have, but I didn't know. I got into the IBM clones with gwbasic then QBasic. QBasic opened my eyes to programming without line numbers. It wouldn't be until college that I realized how limited I was, but by then, I at least understood looping, branching, etc. I flourished while a lot of my classmates floundered. (Professors who were teaching OOP but didn't understand what OOP was or didn't know how to teach OOP didn't help matters.)
Thanks again for the info.
(Score: 3, Informative) by Marand on Tuesday March 01 2016, @01:29AM
Oh, I forgot to mention something else. Since you seem to prefer static typing (based on other comments you made), you might also be interested in static typing for Clojure [github.com]. It's an optional addition to Clojure (and ClojureScript) that lets you choose when you want to use stricter typing.
(Score: 1) by DannyB on Thursday February 25 2016, @07:28PM
> With C# / Mono controlled by Microsoft and Java controlled by Oracle, what cross-OS,
> mature languages would you recommend to replace them that is well used,
> well supported, and can help put food on the table?
An open source OpenJDK (and its java virtual machine) running code produced by open source compilers for a number of languages including Java. Distributions like Debian don't include stuff like that unless it is really free.
With C# / Mono, you have the compiler and runtime. But not everything else that matters.
If you eat an entire cake without cutting it, you technically only had one piece.
(Score: 2) by stormreaver on Thursday February 25 2016, @08:22PM
...and Java controlled by Oracle...
Java is Open Source, released under the GPL. Oracle controls the brand, but not the code. OpenJDK is 100% compatible, in its entirety, with Oracle's Java, seeing how Oracle's Java is built from OpenJDK, and can be forked if Oracle becomes too bad a steward.
(Score: 2) by Common Joe on Monday February 29 2016, @10:44AM
The virtual machine is open source, but who controls the Java language? My Google-fu doesn't allow me to get a clear answer on that. If someone stood up and said "I'm making a new language called [NewJava] and it's forking off the current language specification of Java" and they got a lot of support from the community, would Oracle just sit by or would they try to be evil? That's was what I was trying to say. There's history to this with J# and the Microsoft implementation of it [wikipedia.org], although I don't remember the exact details of it.
(Score: 2) by stormreaver on Monday February 29 2016, @06:43PM
The virtual machine is open source, but who controls the Java language?
The Java specification is determined via the Java Community Process. OpenJDK is created to that specification, and OpenJDK becomes Java and is released under the GPL.
IcedTea is a rebranded Java, but is built from the OpenJDK release. The moment Oracle tries to take Java proprietary, IcedTea is waiting in the wings to take over.
Of course Oracle would try to be evil. It's what Oracle does. But Oracle would lose, assuming the new consortium had deep enough pockets to see the lawsuits through to the end.
J++ is a completely different scenario. Microsoft was telling the world that it provided a Java implementation (J++), when that wasn't the case at all. Microsoft provided something that looked like Java, but was incompatible with Java, in violation of its contract with Sun. When Microsoft lost, C# was born.
(Score: 0) by Anonymous Coward on Monday February 29 2016, @08:24PM
Unless you are sure your app uses ONLY the "clean room" version, Oracle can probably gum up the works in practice. Even if a clean-room-only code analysis tool were created, most wouldn't bother to use it until a problem arises per intellectual property claims, at which point it may be too late.
What's needed and wanted is a from-scratch open-source statically-typed language with a Java/C-sharp-ish flavor to it. If it's half in Oracle/MS court, they can muck with it in practice. You need a full divorce (or never dated) relationship with those snakes.
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @02:33AM
Ages ago he mentioned he tried to work for MS. A lot of what he did in FOSS was very MS inspired, if not pro MS. Well, he finally got the job officially.
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @03:18AM
Remember that MS borrowed the architecture of both C# and .NET from Java, whose momentum they were afraid of in the late '90s and early '00s - even though MS had its own competitive enterprise stack (DCOM/COM+) at the time.
In fairness, what Miguel and Ximian/Xamarin did is hardly unique. Hadoop and HDFS were knockoffs of Google's MapReduce/GFS, Mesos came from Google's Borg, etc. Even the original Oracle database lifted all the work on relational databases and SQL described in journal papers published by IBM's labs. In each of these cases, there was still a ton of good engineering work that had to be done, and remains to be done even after the product ships.
(Score: 4, Insightful) by RedGreen on Thursday February 25 2016, @03:34AM
First thing I thought when I seen the article was finally being brought back in after years of undercover undermining work.
"I modded down, down, down, and the flames went higher." -- Sven Olsen
(Score: 1, Informative) by Anonymous Coward on Thursday February 25 2016, @04:42AM
Xamarin Quits Pretending to be Separate From MSFT; All Staff to Work Directly for Redmond
Roy Schestowitz at TechRights reports [techrights.org]
-- OriginalOwner_ [soylentnews.org]
(Score: 4, Insightful) by canopic jug on Thursday February 25 2016, @06:00AM
Historically, M$ has implied that it would use software patents against those using C#/Mono/.NEt. M$ has been ramping up its patent attacks against FOSS in general so I guess Roy also takes it for granted since he did not mention them. But in addition to copyrights and trademarks, patents will continue to be one of the avenues of attack from M$. C#/.Net/Mono are all garbage and not a technical threat. With the push that M$ makes to squeeze them into where they don't belong, they become a vector for patent attacks. There is the threat.
Unfortunately Oracle did a lot of damage (intentionally) to Java's future through their court antics over the API. Prior to that we had two separate, independent implementations of Java. That was a key in guaranteeing its future. Perhaps the API decision can be overturned but until then the future is dimmer for Java.
Money is not free speech. Elections should not be auctions.
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @08:10AM
Xamarin Quits Pretending to be Separate From MSFT; All Staff to Work Directly for Redmond
reports [techrights.org]
(There was supposed to be a crunch before post-89639.)
-- OriginalOwner_ [soylentnews.org]
(Score: 1, Funny) by Anonymous Coward on Thursday February 25 2016, @04:46AM
By virtue of adding more layers of abstraction they are outperformed by native code and always will be. Even if the difference is minimal, these differences add up at the end and become significant.
(Score: 3, Insightful) by Common Joe on Thursday February 25 2016, @06:58AM
Bleh. Someone marked this as insightful. I think it's trollish. I agree with the statement all frameworks suck, but frameworks done well can be a good thing. It all depends on what you need. Sometimes a single line of code in a high level language or a framework can get a lot of stuff done in a minimal amount of programmer's effort and time even if the sacrifice is some extra CPU cycles.
Using the parent's logic, we should all be using assembly.
(Score: 2) by maxwell demon on Thursday February 25 2016, @07:45AM
Real programmers don't use assembly. They type the machine code directly. ;-)
The Tao of math: The numbers you can count are not the real numbers.
(Score: 1, Funny) by Anonymous Coward on Thursday February 25 2016, @11:18AM
TOGGLE SWITCHES FTW.
(Score: 2) by AnonymousCowardNoMore on Thursday February 25 2016, @03:28PM
Pfft. You kids with your fancy "user friendliness". REAL programmers code with jumper cables.
(Score: 2) by Marand on Thursday February 25 2016, @08:24AM
By virtue of adding more layers of abstraction they are outperformed by native code and always will be. Even if the difference is minimal, these differences add up at the end and become significant.
I get so tired of seeing this argument. I can't even tell if it's a troll or not anymore, because enough people parrot it seriously that it's not possible to tell who's serious and who's fucking around. This sort of comment is essentially saying "performance is the only thing that matters" and it's just not true.
The whole point of abstraction and high-level languages is to take away as much work as possible from the human and push it onto the computer, because our time is supposed to be more important. You shouldn't always work at the lowest level possible and waste time over "MUH PERFORMANCE!" No, you should work high-level and optimise performance where and when necessary. That's the whole damn point. If performance were the only concern we'd all still be using assembly for everything.
Furthermore, it's not a black-or-white "X is always fast, Y is always slow" situation. You can write shit algorithms in a fast, native language and guess what? It will be shit. First place to look for performance bottlenecks is almost always your own code, because you're probably solving the problem in a naive way or doing something inefficiently. Usually fixing that is enough.
It's also not a binary "use this or use that, no in-between" situation. These arguments always present a false dichotomy of "low-level and fast, high-level and slow" that just doesn't exist in real life. If it turns out that improving algorithms isn't sufficient and your platform or language of choice isn't good enough, there's also the option of moving part of the code to something faster. Most languages have some form of foreign function interface [wikipedia.org], so you can isolate the bottleneck and move it to something else that will yield better performance.
Another consideration is what you're doing. Not everything needs to be hand-tuned to perfect performance, because some stuff just doesn't matter. You might want instant startup time for a tool that's intended to be called often and only run in short bursts, for example. You'd tune that for startup time and whatever its most common workload is. On the other end, if you're writing something intended to be loaded once and left running, startup time is less important. Time spent tuning start time could be better-spent improving things like UI responsiveness or other problems.
Also, a problem with the "performance is everything" mentality is a tendency to use any kludge or weird hack possible to squeeze out that last bit of performance at the cost of maintainability, readability, and portability. The focus should be first on making something correct, and then finding ways to improve it, because a correct-but-slow solution will generally be better than a fast kludge. Like the quote says, "Make it work, make it right, make it fast."
Now, I'm not saying performance never matters, it's just not the be-all, end-all of software. There's a lot more to consider when choosing what to use and when to use it. Right tool for the right job and all.
(Score: 0) by Anonymous Coward on Thursday February 25 2016, @10:20AM
Performance may indeed not matter that much (though on mobile platforms that is questionable), but the fact that you start out at 3MB for a "Hello World" and it grows rapidly from there is an issue.
A framework that uses up more disk space that a fully working app (e.g. dictionary) including assets on a device that has hard and tight disk space constraints still in most cases isn't really something that sounds like a sane choice to me unless you only about a tiny piece of the market. And not too much about user experience.
(Score: 2) by Marand on Thursday February 25 2016, @11:50AM
Performance may indeed not matter that much (though on mobile platforms that is questionable)
What's questionable about it? Everything I said applies to mobile, too. Most parts of a mobile app don't need to be blazing fast because it'll still spend more time waiting on user input, network data, etc. In the case of mobile, you try to keep startup time low* and tune the performance of UI response. It doesn't have to be fast, it just has to feel fast. So, again, make it work, make it correct, and then once you know what you need to improve, you can make it fast.
but the fact that you start out at 3MB for a "Hello World" and it grows rapidly from there is an issue.
So what? A "hello world" is a poor metric for anything, it's just a way to give someone a very basic, "quick start" type idea of how a language looks. For anything of reasonable complexity you're going to need to bring in a bunch of extra code to get anything done, or create it yourself. The idea of frameworks, platforms, and other abstractions of the sort is to provide the parts you most likely want out-of-the-box. It's the difference in "batteries included" or "batteries not included" - you'll need batteries either way, but you have to get your own if they aren't provided. That's what things like Java (the platform), .NET, Perl, Ruby, etc. try to do.
A framework that uses up more disk space that a fully working app (e.g. dictionary) including assets on a device that has hard and tight disk space constraints still in most cases isn't really something that sounds like a sane choice to me unless you only about a tiny piece of the market. And not too much about user experience.
Are you talking specifically about Xamarin (or some other platform) now, or is this still generic ranting against abstractions being bloat? The original comment was about "all frameworks", but now it sounds like you're trying to shift it back to something specific because you've got a bone to pick about a specific platform you don't like. Which hey, it's fine if you are, but if you're going that route you should name the offenders so people can respond better.
On a more general level, it just depends on the framework and how it's made and works. I know nothing about Xamarin, but I believe Qt (which can target android, at least; don't know about iOS) doesn't force you to include anything from the framework that you don't need (or is needed by something you include), which lets you cut down on the size a bit. The problem, though, is localization dependencies can get pretty heavy (see here [forum.qt.io]) because it's a hard thing to get right. Though it seems to be something you can remove if you really, really need to.
This goes back to considering the situation and picking the right tool. For something that's barely more than a hello world, sure, you'll probably want to skip using anything that isn't built in because you aren't doing much anyway. Especially for mobile where they're already providing a "batteries included" experience, you might not want to bother. However, for a larger project, especially one with art or audio assets, the framework's size will be trivial. And, if you're interested in targeting more than one platform, being able to use a lot of the same code across platforms could very well be worth it.
Another example of sorts -- it's about languages rather than platforms -- is languages that target the JVM. Languages like Scala and Clojure include a runtime that adds to program size because they're essentially Java libraries that provide more abstractions and features. So, you can think of them like frameworks in a way, because they do a lot of the same things. You use them to make your work easier versus working in plain Java, and it is completely worth it. Rather than writing an entire application in Java, you can write most (or even all) of an app in one of them and if it turns out some part of it doesn't perform well you can move that bit into a Java class. You might have to do some extra work to cut down size or boost startup speed (like ahead-of-time compiling parts of the program with Clojure), but it's worth it to retain your sanity by not having to do the entire thing in Java. :)
* or give the illusion of it, like displaying a screenshot of the last state while the actual UI loads; I believe Apple suggested that for iOS devs at one point.
(Score: 1, Insightful) by Anonymous Coward on Thursday February 25 2016, @07:07PM
>What's questionable about it?
First and foremost, the fact that we're reading this exact same drivel for 30 years minimum. Guess how reality-based your claims were back then; and they hadn't improved that much since.
Yes, you and I do have several orders of magnitude more computing power to waste now; but the "performance is meaningless" crowd has produced a lot of equally effective power-wasters, so you can slow a today's system to a crawl doing nothing of value just as easily as your spiritual predecessors could their 8086s.
The difference is, now with mobile you are wasting not just the user's time, but also battery power.
Go green - learn to write better code! ;)
(Score: 2) by Marand on Friday February 26 2016, @12:36AM
First and foremost, the fact that we're reading this exact same drivel for 30 years minimum. Guess how reality-based your claims were back then; and they hadn't improved that much since.
What's drivel about what I've said? I'm saying the computers work for us, not them, and we should work smarter. Instead of blindly, and ignorantly, trying to optimise everything, developers should be identifying the parts that matter and focusing on them instead to get the maximum benefit for the work. There's little point optimising something that won't see much end-user benefit when there are other things to be done. And there's always going to be other things that need doing.
Frameworks are a part of this. If you need what the framework does, you either use it or re-create it yourself. If you go the DIY route, you're going to end up with one of three situations: 1) it does a lot less, 2) it runs a lot worse [performance or bug-wise], or 3) both. Using something mature instead of trying to roll your own can benefit the end user as well as you if done well, versus tossing out mature, tested, and likely performance-tuned code to roll your own.
Unless, of course, what you're doing doesn't use enough of the features to benefit, in which case ignorantly using a huge framework or library "just because" is just as foolish as the people blindly refusing to consider them because programmers all seem to think they're superior to every other programmer and can re-write the same thing but better.
Yes, you and I do have several orders of magnitude more computing power to waste now; but the "performance is meaningless" crowd has produced a lot of equally effective power-wasters, so you can slow a today's system to a crawl doing nothing of value just as easily as your spiritual predecessors could their 8086s.
The difference is, now with mobile you are wasting not just the user's time, but also battery power.
Go green - learn to write better code! ;)
Performance isn't meaningless, and I never said it was. You're trying to imply that's my position here, but it's not -- which is a strawman fallacy, though possibly unintentional.
People that think performance never matters are just as foolish as the ones that think performance is the only thing that matters, just on the opposite end of the spectrum. That's the point of the "make it right, make it fast" idea, because once you make something correct you can go back and make it fast where it matters, but it's much more difficult (sometimes even impossible) to make wrong code fast. That said, if you never get to the "make it fast" part, you're still not quite there, because that's still important, just not the only thing that matters.
(Score: 4, Interesting) by Common Joe on Thursday February 25 2016, @04:55AM
I've tried Xamarin's IDE. It was decent enough, although I found Microsoft's IDE better. Together, they had the best two IDE's that I've been able to find for non-web development purposes. (I wanted to see more IDEs because Xamarin had a lock-in on Mono.) Yes, there are other IDEs, but many are underdeveloped. (Last time I checked, Monodevelop seemed pretty dead.) Take, for instance, Notepad++. I use it all the time, but it is nothing like the Microsoft or Xamarin IDE when it comes to doing certain kinds of programming.
It really disheartens me to see this because I value cross-OS development. Love it or hate it, C# and Java are the leading cross-OS, non-web languages out there. This effectively makes these languages controlled by Microsoft and Oracle. (Yes, there are different implementations of the JVM, but Java ultimately thrives or perishes based on Oracle's desire to support the language or not.)
Prediction? Because Xamarin leads the way for Java development on a mobile, Linux based platform, I believe Microsoft is making a significant move to weaken Oracle, buy Oracle, and then assume control of Java. They would effectively give them control of mobile (non-web) development and both major cross-OS languages. Expect them to start making small but important steps to intercept PHP in the coming months.
What has happened is a terrible thing in the Linux world and in the app-development world no matter which language you use and no matter which OS you use. If you want to develop mobile (non-web) applications, you'll eventually be using Windows to do it.
Ultimately, this move to buy out Xamarin is also a step to weaken Linux. Before you think I'm a crazy nutter, think about how many cross platform (cross-OS) projects and languages there are that used by a lot of people. The next more developed language I can see for cross platform is Python. The language needs to mature more before it is as good as Java or C#. (I'm not saying Java or C# is good. I'm saying they are more mature than Python.) Python's strength is in its libraries.
Jeez. It's not even 6:00 AM my time and I need a drink.
(Score: 2) by maxwell demon on Thursday February 25 2016, @07:48AM
Maybe it would help if instead of saying "all IDEs except X suck" people would say "an IDE that doesn't suck has to have the following features".
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Funny) by Marand on Thursday February 25 2016, @08:34AM
Maybe it would help if instead of saying "all IDEs except X suck" people would say "an IDE that doesn't suck has to have the following features".
My IDE of choice is emacs so uh...desired feature list: "all of the them". It would be probably be shorter to list things it can't do. :)
I will say though, there's one cool thing I discovered in Light Table that I wish more IDEs would pick up. When using a language that supports it, you can do in-line evaluation; you hit a shortcut (ctrl-enter by default I believe) and it evaluates the line you're on and displays the result in the buffer itself, alongside the evaluated line. No extra window, no popups, no status thing, just boom! result right next to your code. It's tied to the REPL session you've got so you can eval whole buffers or multiple lines, poke at the program's state, etc. and see it right there.
Of course, emacs can do it too. ;) Though the only language I've seen support it in emacs is Clojure (via cider), whereas it's a more general feature in Light Table.
(Score: 2) by maxwell demon on Thursday February 25 2016, @08:38AM
Not surprisingly, it also works for Emacs Lisp.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by Marand on Thursday February 25 2016, @10:51AM
Oh yeah, I use that a lot in the scratch buffer so I don't know why I forgot to include it. Though it's not as nicely done as cider or light table it's definitely the same concept. That and a good REPL are huge benefits.
(Score: 2) by tangomargarine on Thursday February 25 2016, @03:07PM
The idea of Microsoft and Oracle having a knock-down drag-out no-holds-barred fight which resulted in both of them being significantly weakened gives me a warm fuzzy feeling inside.
"Is that really true?" "I just spent the last hour telling you to think for yourself! Didn't you hear anything I said?"