Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I would want to seriously begin multi-threaded/parallel/concurrent programming in real world. By that I mean like trying to solve real problems in parallel and concurrently and not just learning about low-level details of pthread or MPI, locks, races and the like or academic, text-book examples. Regarding low level mechanism of parallel programming, in fact I would rather not know anything about them and just stick with something more like Actor model :).
I have heard that some programming languages are inherently like what I am looking for and their paradigm is to look at the problem at hand in a parallel (concurrent, multi-threaded, multi-processed) fashion and provide language level tools and constructs to implement the task in parallel (e.g. Erlang has a concept of process as a language construct?).
I fancy a language with a type system like that of Scala ... I know PHP very well and I used to do a lot of coding in C/C++. I have a working knowledge of Scala and Java and I can read Haskell but I'm not particularity proficient at it. I'm quite familiar with Functional paradigm and I'm willing to learn much more. I am also interested in high level theoretical discussions about parallelism/concurrency.
I'd like to mention first off that parallel != concurrent. They're closely related concepts, but parallel computation is distinction from concurrent computation in that parallel flows of control happen simultaneously while concurrent may be interleaved but could possibly be parallel. A fine hair to split, but one that's important to understand.
... provide language level tools and constructs to implement the task in parallel (e.g. Erlang has a concept of process as a language construct?).
An Erlang 'process' is a light-weight, memory isolated green thread. The language provides no shared memory constructs; data is passed between concurrent flows of control via 'messages'. Notice is said 'concurrent'. Erlang is explicitly designed to be a concurrent language and, it just so happens, will schedule some flows of control--which map 1:1 onto processes--in parallel. Erlang does not give you explicit control over scheduling, which is unlike the threading model.
It's hard to know what you're looking for--your question is rather broad--but any of the languages you've mentioned (except maybe PHP?) will allow you to exploit the multiple CPUs that are surely sitting in your computer. Pick several to focus on, expect to spend several years studying and go for it.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I've never programmed in a "pure" functional language. I earned my stripes on C and C++, tried Java, C#, PHP etc... but always I found myself going back to C++. Perhaps I'm a bit of a masochist, but I love the low level stuff.
I also find that I can accomplish rapid development quickly through the embedding of LUA, Python or other scripting languages (along with their focus on rapid development).
Long story short, I'm not quitting C/C++ so don't talk me out of it. However I've had little time to learn C++11 and I'm starting to feel the acceleration of the curve towards functional programming happening in the future.
My question is twofold. What language was C++11's concept of lambda functionality "borrowed" from, and what language would be the ideal one, if not that one, or if any to get a feel for "the way" to use C++11's new lambda functionality (no pun intended).
PS: I'm honestly not too happy about the new "bloated" additions to C++. I liked C++ how it was, it's starting to feel like the language is becoming bloated. I won't clam that to be a fact; I hear you have to have experienced a functional language to "get it".
It honestly seems like there is a new heavyweight in town. First it was just "procedural" programming, then came the OOP paradigm shift, while now it seems like things are heading towards the "functional" way of doing things.
Of course procedural programming is still alive and well (inside classes), I have to wonder where the lambda way will fit in (properly used) to class/oop design. Will it just be a replacement for the procedural part? Make OOP a thing of the past (pfft)? Or something else entirely (say, a functional event system generating events for objects encapsulating procedural code)?
I would try to curtail your opinions until you have more rigorous experience of the issues involved.
To paraphrase Bjarne Stroustrup: Functional programming has had a lot of airtime in academia over the last several decades, yet the number of deployed functional systems in industry remains about zero.
More concretely to your question, a lambda is just a short-hand syntactic way to declare a singleton functor object (a class with an operator() function) that captures variables from its enclosing scope as member variables. I wouldn't consider it a "functional programming" concept, any more so than any other entity in C++.
Functional programming generally involves immutable data types (objects that dont change once constructed) and pure functions (functions that have output that depends purely on their input, and nothing else).
If you are interested in functional programming there is a free online course (MOOC) starting right now called Functional Programming Principles in Scala, that serves as a very good and highly regarded introduction to the subject from one of the top Swiss universities.
I can't speak about lambdas in C++11, but I know that part of the rationale for adding lambdas to Java 8 is to enable transparent concurrency support out of the box. How? It provides a (lazy) Stream interface where you can switch between parallel and sequential processing simply by calling parallel and sequential (these methods return new streams, and do not have side effects on existing streams).
If you look at the methods in Stream, you'll quickly notice that without a lambda facility, they would be an extreme pain to use. Have a look at some examples of what you can do with streams in combination with lambdas.
It should be possible to implement a similar library for C++11, if there isn't already such a library.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Disclaimer: Yes I know this will take 3 years, at least.
I am looking forward to writing a new interpreted programming language. I have a quite solid idea of what I want in terms of dynamicness, syntax, object model, etc, etc.
Now that I have the idea, I have a few questions before I start:
Should I begin writing the full specification and then implement, or write them both all along?
I'm still doubting between C and C++. C++ would allow for more clean design and faster development while C would (maybe) ensure portability to more platforms (microprocessors?). Performance is a must.
Should I try to interest people for the project before the first working prototype so they can cooperate (the end product will be a liberal license anyway), or keep working alone until I have something that runs?
How modular should it be? I am sure that I won't immediately start working on a bytecode interpreter but something easier to implement but slower thing first, so modularity is a must in order to be able to extend later, but I guess overdoing it will hamper performance and clearity.
The answers to your questions depend largely on why you're doing this- the primary reason. Are you trying to create the next Ruby, or is this a learning exercise?
Specification: If this is a personal project, this is not as important. PHP gets a bad rap for having been developed "on the fly," yet many people use it every day. A more complete spec will probably help get people involved if/when you want help.
If you want cross-platform and performance, C is the way to go.
If you want people to join in, prove something first. Write a killer-cool application with your language and blog/talk about why your language is different/special/better.
Modularity of what, the language itself or the compiler? If you want to extend the language, a good spec will help (see #1.) The compiler should be designed with all the best practices in mind, which should help make it extensible.
I hear the Dragon Book is good for learning to develop compilers.
Your specification will be broken unless you write it hand-in-hand with the implementation.
If you think C++ would give you cleaner design and faster development, you should probably use it.
You will have difficulty getting anyone interested in a project unless there is something that runs and demonstrates what is unique about your language.
If you think your language will ever require a byte-code interpreter (and you do say "Performance is a must") you should investigate the capabilities of existing byte-code interpreters before you finalize your language design.
I think you have set yourself too many goals. You say "performance is a must" but in a comment reply you say your goal is "to learn a lot about language design" and that it is "pretty unlikely" that you'll use it in a real project. New programming languages are created to solve problems; more precisely, they're created to help people express solutions to problems in better ways. Designing a language without using it seriously, intensely, continually is like writing software without any test cases: you're likely to wind up with something unusable.
If you want to try your hand at language design, then find a problem---one that you care about---that existing languages won't let you solve the way you want. Then do whatever you can to get a working implementation and start writing and running programs using it. You don't need a hand-crafted JIT compiler with a runtime written in highly bummed assembly code. If you target the JVM or .NET, you get a very high-performance GC, scalable threading system, libraries, and lots of other good stuff for free, even if it interferes with that awesome idea you had for ______.
On the other hand, if you just want to make something run fast, don't try to design a language at the same time. Just find one that you like, learn about implementation strategies, and see if you can do better.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
In class the professor said that students shouldn't say that they learned to program in Verilog. He said something like Verilog isn't used to program it's used to design. So how is Verilog different from other programming languages?
Verilog, just like VHDL, is meant to describe hardware. Instead, programming languages such as C or C++ provide a high level description of software programs, that is, a series of instructions that a microprocessor executes.
In practice, Verilog and VHDL do not offer the same features as programming languages, even though they look very much alike. For instance, a for loop in C/C++ describes the sequential execution of a given snippet of code; instead, a for ... generate loop in Verilog/VHDL describes multiple parallel instances of a same hardware building block (say, a AND logic gate). To be precise, there also exists a plain for loop in Verilog, but again, it has to be "synthesizable", that is, the compiler must be able to generate logic that fits the description.
Typically, a beginner in Verilog/VHDL will be tempted to "translate" a given function/algorithm from a C/C++ type of pseudocode directly to Verilog/VHDL: surprisingly, it might sometimes work, but it always lead to dramatically poor design. One must really be aware of these differences in order to become a good Verilog/VHDL programmer.
Verilog is a hardware definition language. Programming languages are generally understood to be languages for telling existing hardware what to do, not for reconfiguring said hardware.
I don't know anything about Verilog but just did a quick googling and the wiki pages seem to do a pretty good job of explaining the differences in concept that your teacher seemed to be eluding to. As some of the other posters here wrote I don't know that I would dismiss this as not a programming language, I think there's a high tendency for programmers to believe if it isn't somehow application programming or assembly programming then it's not really programming, but in short that's BS. Everything above machine code is basically the same to me, if it's a file I give to a computer and it tells the computer how to do something it's programming the computer (I guess the problem is drawing a line between users and developers, we like to feel special). Unless we plan to roll back to punch-cards sometime soon, I think anything that has a C like syntax or allows you to describe in a syntactically strict (well defined) way and modifies the behavior of the computer (what it outputs for a given input) then you've done some programming in one sense or another.
http://dictionary.reference.com/browse/programming
From the wiki page:
http://en.wikipedia.org/wiki/Dataflow_language
Dataflow programming focuses on how things connect, unlike imperative programming, which focuses on how things happen. In imperative programming a program is modeled as a series of operations (thing that "happen"), the flow of data between these operations is of secondary concern to the behavior of the operations themselves. However, dataflow programming models programs as a series of (sometimes interdependent) connections, with the operations between these connections being of secondary importance.
(I think the key here is the qualifiers of the type of programming not that one is a "programming language" and the other is a "design language", from what I understand they're both programming languages they just have distinct purposes and implementations). When I think of design I basically think of this:
http://dictionary.reference.com/browse/design
and that is not a program although a program may utilize designs (and probably should, generally referred to as design patterns, but not what you're doing)
Linked in from: http://en.wikipedia.org/wiki/Verilog
To your teachers point this language would likely be used to solve different problems from your every day Java/C program, and via a different means, however to say it is not a program seems wrong.
Because it is an HDL, so it is to define hardware, and anything done in verilog (not really anything, but synthesizable things) will be synthesized into actual hardware. So you can't just use programming features like class and OOPS concept because it can't create any hardware.
But in C, everything will be converted into executable hex file, which will be loaded in your ram while executing the program.
Another basic difference is everything in hardware is concurrent, so if you have written a=b+1 and c=d+1 in verilog, then in the synthesized hardware, both modules will work simaltaneously. But in C everything is sequential, so in same C program actually both instruction will be loaded one by one in your processor.
It is a programming language, not to program software, but to describe hardware design - but the output is not necessarily an "application" as we understand it.
The language has a formal syntax.
Verilog contains features to describe logical netlists(RTL) and features to facilitate simulation of them. Describing an RTL description as a program may convey that one who describes it as such does not throughly understand logic design or synthesis. Describing a testbench stimulus as a program would be appropriate.
verilog/vhdl is used to create and design specific application system on the chip which embedded into electronic devices.
c/c++ used design softwares on the computer
I am going to tackle this question in a different way. What is a purpose of a programming language? Can the output of a program affect real world and your goals and expectation? If yes then ofcourse verilog is a programming language. Console.log has as much meaning as what it translates to in real world eg. console.log("you have a million unit") has no fiat without authority. So verilog is a programming language in certain sense.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
To me, I think F# is a bad choice due to the fact that it uses threads behind the scenes. To me, threads are too "heavy" due to things like context switching.
I can see why Erlang is a good choice because it uses light weight processes.
Am I wrong?
I don't understand what you are asking.
F# does not use 'threads behind the scenes', or at least no more than any .NET process does. In fact F#'s async facilities make it much easier to write non-blocking I/O programs that do not consume threads (as compared to C#/VB which has a more difficult threadless/non-blocking programming model).
(And, of course, typically you don't just pick one arbitrary aspect to compare two things and then decide 'X is better than Y'. There is more to a programming language than just a threading/process model.)
You may enjoy reading
http://blogs.msdn.com/dsyme/archive/2010/02/15/async-and-parallel-design-patterns-in-f-part-3-agents.aspx
The final three paragraphs are worth quoting:
Indeed, there are few other .NET or
JVM-based languages that support
lightweight reactive agents at all –
in early .NET it was said to be
“impossible” because of the costs of
threads. In this context, F#’s
integration of “async { ... }” in 2007
can be seen as somewhat of a
breakthrough in applied language
design – it allows lightweight,
compositional async programming and
reactive agents in the context of an
industrially accepted and
interoperable programming platform.
Along with the Axum language prototype
(which has been influential on F#), F#
has proven that an asynchronous
language feature is a feasible way to
break through the logjam of “do we
make threads lightweight or not” that
currently bedevils industrial runtime
system design.
F# async programming can be seen as an
implementation of resumptions, and
there are many precursors here, for
example OCaml delimited continuations,
Haskell embeddings of monadic
concurrency and papers emphasising the
importance of resumptions with regard
to concurrency.
You can use F# asynchronous agents on
.NET 2.0, 3.5, 4.0, on Linux/Mono/Mac
and on Silverlight. Indeed, you can
even use F# async programming when F#
is translated to Javascript using the
WebSharper platform. Enjoy!
Since 2006 erlang has had SMP, so it too 'uses threads behind the scenes'. Neither a process in erlang nor (AFAIK) asynchronous tasks in F# correspond to an OS thread; both runtimes use threads as and when required, and lighter-weight mechanisms where appropriate.
If you want to get some useful feedback, you should specify the scenario you are interested in. However, functional programming isn't about threads or processes - it is more about expressing algorithms and using different programming patterns, so the use of threads/processes is a really weird criteria for comparing functional languages.
Most importantly, in F# concurrent programming is just a matter of library and there are many choices:
F# async mentioned by Brian allows you to implement light-weight message-passing concurrency
PLINQ allows you to write declarative data-parallel computations
Tasks give you a fine-grained primitive for executing a large number of small tasks in parallel
Threads (used rarely) give you the full control over closer to the operating system level
On the other hand, Erlang pretty much forces you to use a single library for concurrent programming (which is directly supported by the language). That may be a good choice for many areas (such as telecommunication applications), but it may be too restrictive for some other cases.
I'm not saying anything bad about Erlang - you can certainly use it to encode many other higher-level concurrent programming paradigms as well. I'm just saying that binding the language to a single concurrency programming model (and using this to compare the languages) is a wrong approach in general.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have lately been delving into F# and the new DSL stuff as in the Microsoft SQL Server Modelling CTP, and have some concerns.
Will this new idea that will come about be bad for skilled programmers?
Is code going to be dumbed down?
I know I sound like a luddite, but this does worry me, after spending years of time practising in my craft, and now might be scuttled by genius from within.
I am afraid, very afraid.
Will I be now trapped in a job that only programs against a DSL and therefore every job that I work on, I have to learn a whole new DSL based on top of a Framework (.net Java), that I will only be allowed to touch certain parts of.
I don't think the world is ready for DSL, but the sales pitch is deafening!
DSLs will liberate programmers from doing a non-programming stuff. Cleaner separation of responsibilities is always a good idea. Programmers should program (e.g., implement DSLs), and other domain experts should do what they are good in. I am personally doing whatever I can to turn this industry towards a wider use of DSLs. I do not want to code business logic. I love to implement compilers. So I'm not afraid. I am looking forward for a time when every little task will require its own little DSL.
There will always be a need for real, knowledgeable programmers to construct those DSLs and to add new capabilities to them as requirements change. No problem domain is static.
I wouldn't worry, DSL's are a long, long, long ways away from being embraced by your average corporate IT department.
I am developer and I frequently design my own DSLs and DSL2Text transformations to speed up many boring parts of my job. To this end I use the Eclipse plugins (i.e. EMF, XText, ACceleo, etc.) as explained in this site http://lowcoupling.com/dslengineering
I think DSLs in reality will elevate the levels of software engineering work. Here are the reasons:
Think of ORM or SQL DSLs. It models SQL access in your native programming language. It reduces complexity, allows higher level constructs, is more readable and is less error prone (than SQL string manipulation). A good SQL DSL is composable. Trying to achieve what a SQL DSL does with Ad Hoc code on the fly is way too difficult and error prone. In this case, a DSL reduces mundane complexity and elevate the level of your code into higher level abstractions. (Same concept as we don't want to code every TCP/IP handshake every time we open a TCP connection).
Many DSLs are not meant for software programmers. When we design DSLs, often they are handed off to domain experts (who are non-programmers) to use. These easier DSLs will not require programmers, so you won't be stuck using them. The software field is currently dumbed down because we have schools churning out programmers that code simple ASP.Net pages. Shifting these type of mundane work to non-programmers will force schools to produce higher quality engineers.
Good DSLs hide complexity, but they are flexible, and allow users to customize/fine tune behaviors when needed. This means they won't confine programmers into rigid/mundane coding behaviors.
When a problem is highly complex, it's usually better to reduce it into a domain specific problem and construct a mini DSL for it. DSL code is simply more relevant and easier to maintain, and the business logic will be shorter, easier to verify and easier to reason.